Bluetooth^® Mesh Directed Forwarding

Technical Overview

View Table of Contents

Release :	1.0.0
Document Version :	1.0
Last updated :	September 19, 2023
Authors :	Martin Woolley, Bluetooth SIG Szymon Slupik and Piotr Winiarczyk, SILVAIR Inc.

Revision History

Version	Date	Author	Changes
1.0.0	September 19, 2023	Martin Woolley, Bluetooth SIG Szymon Slupik and Piotr Winiarczyk, SILVAIR Inc.	Initial version

 

Note The Bluetooth Mesh Profile Specification has been renamed and is now called the Bluetooth Mesh Protocol Specification. References in this and related papers will use this name when referring to the version 1.1 specification but continue to refer to the version 1.0 specification as the Bluetooth Mesh Profile Specification.

 

1. Background

Directed forwarding was introduced in version 1.1 of the Bluetooth^® Mesh protocol specification. To fully appreciate the capabilities and benefits of Bluetooth Mesh Directed Forwarding, it is necessary to understand some aspects of Bluetooth Mesh version 1.0. This section provides context and background which will support the examination of the Bluetooth Mesh Directed Forwarding feature.

1.1 Multi-hop and Multi-path Message Delivery

One of the defining characteristics of a Bluetooth^® Mesh network is that devices can communicate even when they are not in direct radio range of each other. Devices in the network, known as nodes, communicate by sending messages to destination addresses and if necessary, messages will hop across the network until they reach their destination using a process known as relaying. Messages may hop a maximum of 126 times, allowing networks to cover a substantial area in, around, and between buildings.

Copies of the same message may simultaneously travel over different paths through the network with the first copy to arrive being processed and later arrivals discarded. This multi-path capability provides networks with redundancy so that messages can still be delivered, even when one or more required relay nodes (see 1.2) in the network are unavailable.

A well-designed Bluetooth Mesh network will take advantage of multi-path delivery as one of the strategies which can be used to ensure that communication in the network is reliable.

1.2 Node Features

For example, LED lights may implement models which allow them to be switched on or off and have their lightness or colours changed in response to messages received from other devices such as switches and rotary controls.

A node can also play various special roles in the network irrespective of the type of product that it is. Bluetooth Mesh defines four special features which a node may have. These are as shown in Table 1.

Table 1 – Node Features

Feature	Description
Relay	A node which has the relay feature enabled may re-transmit messages which it hears from other devices in its immediate vicinity. Relaying is the mechanism which allows messages to hop across intermediate relay devices to their destination. Multi-path delivery is achieved by ensuring that transmitting nodes are in range of more than one relay node so that each will hear messages from adjacent nodes, and each will retransmit them.
Friend	Friends are typically power rich devices. They provide a store and forward service to associated low power nodes (LPNs).
Low Power Node	LPNs save power by only activating their radio occasionally to transmit messages or to communicate with an associated friend node to ask if any messages for the LPN have been temporarily stored by the friend and to receive any that have.
Proxy	Proxy nodes allow Bluetooth® Low Energy (LE) devices that cannot use the Bluetooth Mesh advertising bearer to send and receive mesh messages using GATT procedures over a point-to-point connection with the proxy. Proxy nodes are often used to allow specially developed smartphone applications to act as graphical user interfaces for monitoring and controlling nodes in a mesh network.

 

1.3 Bluetooth Mesh Managed Flooding

Uncontrolled Flooding is a technique used in some wireless networking technologies and involves nodes re-transmitting every message received so that messages propagate to every node in the network. It’s a simple approach but may be inefficient, wasting radio spectrum and node processing time and power.

The mechanism which Bluetooth^® Mesh 1.0 uses to relay messages is called Bluetooth Mesh Managed Flooding. Only selected nodes may have the relay feature enabled. Moreover, those nodes re-transmit some messages they receive, depending on whether or not the same message has already been re-transmitted, as indicated by the node’s message cache and on the value of a Protocol Data Unit (PDU) field called Time to Live (TTL).

TTL limits the number of hops that a message will be relayed over or the radial distance it will travel from the source. Imagine a set of Bluetooth Mesh light switches in the lobby of an office. One switch controls all of the lighting nodes on the ground floor whereas one of the other switches only controls those lights in the lobby itself. If all of the lighting nodes in the lobby are in direct radio range of the lobby light switch, then there is no need for these messages to be relayed at all. In contrast, to reach other lights on this floor, outside of the lobby, perhaps 2 hops are needed. The first switch will set TTL to 0 in messages that it sends, indicating that no relaying should be performed. The second switch will set it to 3, which will ensure that it is relayed sufficient times to reach the more distant lights beyond the lobby. In each case, TTL is optimizing the relaying function by ensuring that messages are not relayed into areas of the building where they are of no relevance and that messages propagate outward from the source, similar to waves from a rock dropped in water.

In contrast to networks which use uncontrolled flooding and generate a substantial amount of unnecessary traffic, in a Bluetooth^® Mesh network it is common for no more than around five percent of nodes to act as relays.

1.4 Limitations of Bluetooth Mesh Managed Flooding

There are scenarios where more control over precisely which nodes will relay a message than Bluetooth Mesh Managed Flooding can offer would be advantageous. Consider the following scenarios:

1.4.1 Adjacent Floors

Radio transmissions travel in three dimensions. A Bluetooth^® Mesh message may therefore be received by nodes on floors above and below the floor from which it originates, and this may be undesirable if the message is addressed only to nodes on the same floor as the originating node. For example, a light switch will often be used to control only the lights on the same floor and there is no value in messages from the switch being heard by nodes on other floors and possibly re-transmitted by relays on those adjacent floors.

1.4.2 Target Devices on One Side of the Room Only

Imagine a large conference hall, with a bank of light switches on the wall, halfway between one end of the room and the stage at the other end. One switch controls the lighting over the stage and messages need to be relayed by one hop to reach all of them.

In the network as depicted in Figure 1, we have two relays in range of the switch, which is necessary to allow other switches in the same panel to reach all of the lighting nodes that they must control. When the stage lighting switch is used, messages will be transmitted, received by both relays and retransmitted, so that the messages travel through the network both towards the target lights and away from them.

Figure 1 – Conference hall with stage lighting and several relay nodes

Figure 2 – The light switch broadcasts an on/off message

Figure 3 – Two relays receive the message and both retransmit

This is wasteful since the relays furthest from the stage do not contribute to the delivery of messages from the switch to the stage lighting and so, ideally, should not be involved.

1.5 Messaging Capacity and Scalability

When a device transmits a message, it makes use of a radio channel for a period of time. Another device which is in range of this first device will cause a collision if it transmits a message on the same channel at the same time. Therefore, within a part of a network where all devices are in range of each other, there is a finite messaging capacity, since all transmitted messages make use of a radio channel for a period of time and only one at a time may safely do so.

The time consumed per message is short and Bluetooth^® Mesh uses three radio channels. But the capacity is still finite and will ultimately act as a limiting factor in the scalability of the network.

1.6 An Appraisal of Bluetooth Mesh Managed Flooding

Bluetooth Mesh Managed Flooding is a system for propagating messages through a network. It provides range and area coverage through its multi-hop capability and in a suitably designed network, with thoughtfully placed relays, it provides redundancy through its multi-path relaying behavior.

Message caching and the use of the TTL parameter allow some control to be exercised over how far messages will travel, and this provides a degree of optimization. Relays are completely independent of each other, which means there are no dependencies or configuration settings which must be maintained in the event that something changes, such as a device being moved. For most cases, Bluetooth Mesh Managed Flooding is a fit for purpose solution which requires very little maintenance.

Whilst TTL can be used to limit the number of hops a message might take, it cannot provide any control over the direction of a message through the network. Bluetooth Mesh Managed Flooding causes messages to ripple outwards across the network in all directions and therefore may make wasteful use of the finite messaging capacity in parts of the network for which a message has no relevance.

There are network design scenarios where Bluetooth Mesh Managed Flooding does not deliver the most efficient network utilization that we might want and in some cases this will limit scalability.

This was the primary motivation for the Bluetooth Mesh Directed Forwarding capability which was introduced with the Bluetooth Mesh Feature Enhancements Version 1.1 release.

2. About Bluetooth Mesh Directed Forwarding

This section reviews the Bluetooth Mesh Directed Forwarding feature.

2.1 Capabilities and Benefits

2.1.1 Greater Scalability Through Improved Utilization

Bluetooth Mesh Directed Forwarding allows a network to be set up such that only those nodes that are able to participate in directing a message towards its destination will do so. Conversely, a node using Bluetooth Mesh Directed Forwarding will ignore any message which it cannot assist in its journey.

Nodes which have the ability to use Bluetooth Mesh Directed Forwarding when originating or relaying messages are called Bluetooth Mesh Directed Forwarding nodes. Those which can relay messages using Bluetooth Mesh Directed Forwarding are called Bluetooth Mesh Directed Forwarding relays. A Bluetooth Mesh Directed Forwarding relay is always a Bluetooth Mesh Directed Forwarding node, but a Bluetooth Mesh Directed Forwarding node may or may not also be a Bluetooth Mesh Directed Forwarding relay. Which term is used will typically depend on the context.

Figure 4 shows that messages from the stage lighting light switch in the conference hall example will only be relayed by one of the Bluetooth Mesh Directed Forwarding relays since it is in a position to deliver these  messages to their intended destination. In contrast, the other directed forwarding relay node in range of the switch ignores these messages. Note that the light switch in this scenario is acting as a Bluetooth Mesh Directed Forwarding node.

Figure 4 – Bluetooth Mesh Directed Forwarding

2.1.2 Easier Network Design and Commissioning

Designing and setting up (commissioning) larger Bluetooth^® Mesh networks which use Bluetooth Mesh Managed Flooding alone for message propagation may require careful thought about issues such as how many nodes to configure to act as relays and where to place them. If too many nodes act as relays, more traffic than necessary will be generated in the network, the risk of collisions is higher, and scalability limited. If too few act as relays, there may be communication problems with some nodes unreachable or there being a lack of redundancy in the design.

Enabling the use of Bluetooth Mesh Directed Forwarding requires little effort when the network is commissioned. All nodes may be configured to use Bluetooth Mesh Directed Forwarding and all they require to work is for a simple set of Bluetooth Mesh Directed Forwarding policy parameters to be set, after which the system will self-maintain and self-optimize the required communication paths.

2.2 Technical Highlights

2.2.1 The Bluetooth Mesh Directed Forwarding Configuration Server Model

A new foundation model called the Bluetooth Mesh Directed Forwarding Configuration Server model has been introduced. It includes a composite state called Directed Control which includes a number of sub-states such as the Bluetooth Mesh Directed Forwarding  state and the Directed Relay state. These states indicate and control whether or not Bluetooth Mesh Directed Forwarding and directed relay functionality is enabled respectively. Given the relationship between these two functions, the directed relay state is bound to the Bluetooth Mesh Directed Forwarding state so that if the directed forwarding function is disabled then so is the directed relay function.

The presence or absence of the Bluetooth Mesh Directed Forwarding  Configuration Server model determines whether or not a node has the potential to use Bluetooth Mesh Directed Forwarding . The value of the Directed Control state determines which Bluetooth Mesh Directed Forwarding functions are enabled or disabled.

2.2.2 Paths

The selective participation of Bluetooth Mesh Directed Forwarding relay nodes in the re-transmission of only certain messages and not others involves the concepts of paths and lanes. It should be noted that in version 1.0 of the Bluetooth^® Mesh Profile, the term path was used informally. When used in the context of Bluetooth Mesh Directed Forwarding, path has a more specific meaning:

A path is a set of nodes which can participate in relaying a message from a source address to a destination address over a particular subnet using Bluetooth Mesh Directed Forwarding .

The source of a path is always a single node, identified by a unicast address. In the context of Bluetooth Mesh Directed Forwarding, the source node is called the path origin.

The destination of a path is a set of one or more nodes, depending on the type of address which it is used. Unicast addresses, group addresses, and virtual addresses are all valid identifiers for the destination of a path. If the destination is identified by a group or virtual address, then a node that subscribes to that address is called a path target. So, in the language of Bluetooth Mesh Directed Forwarding, a path has a single path origin node and one or more path target nodes.

A Bluetooth Mesh Directed Forwarding node knows which paths it is a part of but knows nothing else about other nodes which service the same path, including which nodes might precede or follow it in message relaying sequence. This ensures that the system avoids complicated configuration dependencies which would make maintenance of the network difficult, time-consuming, or costly, and, as such, Bluetooth Mesh Directed Forwarding retains one of the benefits of the simpler Bluetooth Mesh Managed Flooding method.

A number of illustrations follow. Figure 5 provides a key to the icons used.

Figure 5 – Key to Illustrations

Figure 6 shows a simple Bluetooth Mesh Directed Forwarding path with a light switch acting as the path origin and a single luminaire acting as the sole path target node.

Figure 6 – Path with a single target node

The red icons in Figure 6 represent Bluetooth Mesh Directed Forwarding relays which are part of the path from the switch node to the lighting node which has subscribed to the publish address used by the switch. When the switch publishes its on/off message, it is received by both the red node, which is on the path and the adjacent directed relay nodes (purple) which are not. The red node is aware it is on the required path and so relays the message using Bluetooth Mesh Directed Forwarding. The purple nodes know that they are not part of this path and so immediately discard the on/off message. This prevents the message from travelling further into parts of the network for which the message has no relevance.

Group addresses and virtual addresses may and usually are subscribed to by more than one node. A path whose destination is a group address will typically have more than one path target node. Figure 7 provides an example of a path servicing communication between a light switch and a collection of lights along one edge of a large hall, all of which have subscribed to the path’s group address.

Figure 7 – Path with multiple target nodes

Once again, the switch node publishes an on/off message which is received by all Bluetooth Mesh Directed Forwarding relays that are in range. Only those which know themselves to be on the path from the unicast address of the switch node (the path origin) to nodes that have subscribed to the group destination address of the path (path target nodes) retransmit the message. Other Bluetooth Mesh Directed Forwarding nodes that are not on that path will discard the message. It is clear that Bluetooth Mesh Directed Forwarding offers significant efficiency improvements in scenarios such as these.

How paths are created and maintained will be discussed in later sections.

By way of contrast, Figure 8 depicts the same message, published by the switch to a group address, but delivered using Bluetooth Mesh Managed Flooding relays with a TTL value of 4 to ensure sufficient hops are made for the message to reach all intended nodes.

Figure 8 – Bluetooth Mesh Managed Flooding

For easy comparison, Figures 7 and 8 are repeated here, side by side:

Bluetooth Mesh Directed Forwarding

Bluetooth Mesh Managed Flooding

 

2.2.3 Reliability

A path has already been described as a set of nodes that provide a Bluetooth Mesh Directed Forwarding service for a source address, destination address, and subnet. With Figures 6 and 7 in mind, we can see that when used to deliver a message, a path will generally comprise a number of sequences of nodes through which copies of the message pass as they are relayed along the path to the various target nodes in different parts of the network.

But what if there was a break in one or more of those sequences of nodes? Clearly, if one of the directed relay nodes in one of the node sequences in a path did not process a message for some reason, that part of the path would not be able to deliver messages to a subset of the target nodes. In a scenario such as that depicted in Figure 7, this would mean that the lights in one part of the room would not respond to the message sent by the switch.

All Bluetooth^® Mesh nodes spend some of their time transmitting messages, some of their time waiting to receive transmissions from other nodes (listening on one radio channel at a time) and the remaining time in an idle state. If a node is transmitting or idle, it will not be able to receive messages transmitted by adjacent nodes during that time period. If it is listening to a radio channel other than the one a PDU has been transmitted on, it will not receive the message either.

The proportion of time during which a node is available to receive messages is called the RX duty cycle and is expressed as a percentage. It is recommended that mesh products be designed and configured to have as high an RX duty cycle as possible, but it will never be 100 percent. Therefore, there is always a possibility that a node will not receive a PDU. This is an expected aspect of the operation of a Bluetooth Mesh network and a fundamental characteristic of the stochastic approach which Bluetooth Mesh technology is designed to take.

Bluetooth Mesh nodes typically transmit copies of messages on three different radio channels, one at a time, in rapid succession. In addition, it is usual for nodes to be configured to repeat the multi-channel transmission process a number of times. The use of multiple radio channels helps mitigate the risk of packet collisions, and the retransmission of messages multiple times reduces the probability of intended recipients from missing a message to a very low probability. In this way, by exercising a number of variables which affect the probability of successful communication between nodes, Bluetooth Mesh offers reliable communication without the burden of protocol and configuration complexity which other approaches generally suffer from.

Bluetooth Mesh Directed Forwarding uses multiple radio channels and PDU retransmission at the network layer in the same way that other messaging scenarios do and so enjoys the same reliability benefits. But there can be other reasons for a node sequence to be unavailable or not working. Nodes can be powered off or they can be moved to a new location, for example. Bluetooth Mesh Directed Forwarding offers mesh network designers an additional feature with which to assure the reliability of the network. This feature is the multi-lane Bluetooth Mesh Directed Forwarding path.

2.2.4 Bluetooth Mesh Directed Forwarding Path Resilience and Lanes

The Bluetooth Mesh Directed Forwarding feature defines the concept of a lane. A Bluetooth Mesh Directed Forwarding path consists of one or more lanes.

A lane is a set of nodes which can provide a Bluetooth Mesh Directed Forwarding service for a source address, destination address, and subnet.

That informal definition should already be familiar from 2 where it was used to describe a path. This is not a mistake. There will often be a choice of different sequences of nodes by which a message might be relayed from its source to its destination. A lane is one particular set of node sequences which can provide that Bluetooth Mesh Directed Forwarding service and to maximize path reliability it is possible to configure a node so that when a path is created with it as the path origin, a path containing more than one lane is established.

Consider Figure 6, repeated below alongside Figure 9.

Figure 6 – Path with one lane

Figure 9 – The same path with two lanes

 

Figure 6 depicts a path containing a single lane servicing the directed forwarding of messages from the switch to a lighting node. Figure 9 shows an equivalent path, providing a directed forwarding service to the same source and destination address, but for which two lanes have been established. The network depicted in Figure 9 will be more reliable than that shown in figure 6 because it includes redundancy in the form of multiple possible sequences of Bluetooth Mesh Directed Forwarding relays which can deliver a message to its destination. It will, however, generate more overall traffic in the network.

2.2.5 Path Metrics and Lane Selection

There will often be more than one sequence of Bluetooth Mesh Directed Forwarding relays that could service a path, so a method based on a system of path metrics is defined for ranking the available node sequences during path creation.

In version 1.1 of the Bluetooth^® Mesh Protocol Specification, one type of path metric is defined, but provision has been made for the possibility of adding other types of metrics to the system in the future. At this release, the path metric type which is defined is called the node count metric. This is a simple but effective way of measuring how attractive a particular sequence of nodes is in forming part of a path, compared to alternative node sequences.

The node count metric measures the number of hops a message must be relayed through to reach an intermediate relay or target node summed with a count of the number of lanes (belonging to this path) that the node is a part of. In this way, existing lanes become less attractive at each iteration of the procedure so that new lanes are created.

Path metrics are used when creating paths and lanes but not when mesh access messages are being relayed through the network using Bluetooth Mesh Directed Forwarding. How paths and lanes are created and the role of path metrics in that process will be examined next.

2.2.6 Creating Paths and Lanes

Paths are either created manually using a Configuration Manager tool or are discovered and established dynamically through the execution of a series of automated procedures. Manually created paths are called fixed paths and dynamically created paths are called non-fixed paths.

The Bluetooth Mesh Directed Forwarding Configuration Server model includes an important state called the Forwarding Table. Entries in the forwarding table indicate the paths that the node is part of, and it is the forwarding table that is manually updated when creating fixed paths.

Each Bluetooth Mesh Directed Forwarding node also has a data structure known as the Discovery Table. Temporary entries are created in this table during the automated path discovery process and aid identification of the sequences of nodes that will form a lane of a path.

Non-fixed paths are initially created when Bluetooth Mesh Directed Forwarding is to be used to deliver a message from a source address to a destination address but for which the source node has no entry in its forwarding table.

Three procedures known as Bluetooth Mesh Directed Forwarding Initialization, Bluetooth Mesh Directed Forwarding Discovery, and Bluetooth Mesh Directed Forwarding Establishment must be executed for a path to be created.

Path creation and maintenance is governed by a series of timers and state values in accordance with a state machine called the Path Origin State Machine. Per the name, this important composite state is created during Bluetooth Mesh Directed Forwarding initialization by the path origin node. An identifier called the forwarding number is also allocated during Bluetooth Mesh Directed Forwarding initialization and all control messages relating to a series of initialization, discovery, and establishment procedures have the same forwarding number value.

Having created the path origin state machine and started the path discovery timer, the path origin sends a PATH_REQUEST control message. This message is sent with its DST (destination address) field set to a new fixed group address, all-directed-forwarding-nodes. The PATH_REQUEST message contains another field called Destination which is set to the address of the path target and may be a unicast, group, or virtual address.

Bluetooth Mesh Directed Forwarding discovery proceeds with the PATH_REQUEST message being transmitted from the path origin and then being re-generated and broadcast again by each Bluetooth Mesh Directed Forwarding relay which receives it. In this way, the PATH_REQUEST message is ultimately received by all directed forwarding relays in the network.

Nodes receiving a PATH_REQUEST where the received signal strength indicator (RSSI) is lower than a configured threshold will discard the message. This ensures paths are not created using weak radio links.

As copies of the PATH_REQUEST message hop along the various node sequences, a path metric value is maintained in the message so that the cost of arriving at each node is tracked as the discovery procedure progresses.

The first time a PATH_REQUEST message for a forwarding number is received by a node, an entry is created in its discovery table. The entry includes the identity of the path to be created and the path metric representing the cost associated with the node sequence taken from the path origin to this node on this occasion. In addition, and importantly for the Bluetooth Mesh Directed Forwarding  establishment procedure, the unicast address of the node which preceded this node in this particular node sequence is also stored in a field called Next_Toward_Path_Origin.

When PATH_REQUEST messages are received by nodes which have already been visited via another node sequence during the same discovery procedure, the discovery table is consulted to determine whether the node sequence taken by the PATH_REQUEST message on this occasion is better than the best found so far or not. If the path metric for the sequence this instance of PATH_REQUEST has taken is a lower value than the value recorded in the discovery table then the discovery table entry is updated to include the unicast address of the previous node in this new sequence in Next_Toward_Path_Origin and the new and lower path metric value. In this way, a record of the best node sequence, expressed in terms of the path identifier, path metric, and unicast address of the previous node in the sequence, is maintained in the discovery table of each node visited during discovery.

When a PATH_REQUEST message reaches a path target node (any node that has subscribed to the address in the Destination field), a timer called the path reply timer is started. When this timer expires, the Bluetooth Mesh Directed Forwarding establishment procedure starts. This procedure adds to or updates an entry in the forwarding table to record the fact that this node is part of the newly discovered lane of this path. A PATH_REPLY message is then sent to the node whose unicast address is contained in the Next_Toward_Path_Origin field of the discovery table entry. PATH_REPLY messages hop back toward the path origin node via the intermediate relays in the selected node sequence, creating or updating forwarding table entries in the process, until the message arrives at the path origin itself.

An instance of the path discovery timer, running on each visited node, will expire before the path establishment procedure has finished and, when this happens, the associated entry in each node’s discovery table will be deleted. The forwarding tables on each node that was selected will now contain an entry for the established path which serves simply to indicate that each of these nodes services that path. It should be noted that the forwarding table contains no data indicating either next or previous nodes in the sequence. The address of previous nodes was only required for path establishment and so was only stored temporarily in the discovery table.

Figure 10 – Bluetooth Mesh Directed Forwarding Discovery and Establishment

In summary, path discovery involves PATH_REQUEST messages travelling through every possible sequence of Bluetooth Mesh Directed Forwarding nodes in the network, starting from the path origin. The path metric values of the best sequences discovered so far are noted in the discovery table of each node as the procedure executes. Starting from path target nodes, the node sequence leading to that node, and which yielded the best path metric value, is retraced by PATH_REPLY messages which hop along the nodes in that sequence only using the Next_Toward_Path_Origin unicast address saved in discovery tables until they reach the path origin node, at which point a single lane of the required path can be said to have been established.

Figure 11 illustrates the discovery and establishment procedures in terms of the journeys of PATH_REQUEST and PATH_REPLY messages through the network in creating a path from a switch (shown as a green icon) and a single light node (shown as a yellow icon).

A configuration state known as Wanted Lanes indicates how many lanes a path should have. At the path origin node, when the path discovery timer expires, Wanted Lanes is checked against the number of lanes established so far and if necessary, the discovery and establishment procedures are executed again. At each subsequent iteration of these procedures, a field known as Lane Counter is incremented and, if a PATH_REQUEST message is processed by a node which already has a forwarding table entry for this path, Lane Counter is added to the path metric value. In this way, previously established lanes being revisited will have progressively higher metric values associated with them during each iteration of path discovery. This will result in other node sequences becoming more attractive relative to established lanes and eventually being selected. In addition, the way the path metrics system work, disjoint lanes will generally be preferred.

2.2.7 Monitoring and Maintaining Paths

Networks change and so paths and their lanes need to be maintained. Several procedures and timers concerned with automatic path maintenance are used for this purpose.

All non-fixed paths have a finite life span which is defined in a configuration state. Supported values are 12 minutes, 2 hours, 24 hours, and 10 days. The default lifetime for a path is 24 hours.

Fixed paths persist until removed using the configuration manager application.

Path Lifetime

The lifespan of non-fixed paths is managed using a timer called the Path Lifetime timer, which is set to the configured path lifetime state value and initialized on each node during path establishment. When the timer expires, the forwarding table entry for the path is deleted at each node on the path. The path will be recreated when it is next needed.

Path Monitoring

The Path Origin State Machine is associated with a specific Bluetooth Mesh Directed Forwarding destination and defines a number of timers and states, including the path monitoring timer and the path needed state. The path needed state is used to track whether or not a path is being used by a path origin.

Path monitoring takes place for a period of time at certain, configured intervals.

When the path monitoring timer expires, if the path monitoring has revealed that the path is still needed, the Bluetooth Mesh Directed Forwarding initialization procedure is performed so that the path is refreshed in line with the present condition of the network. If it is not, the path will be deleted when the path lifetime timer expires.

Path monitoring identifies and deletes paths that are no longer needed.

Path Validation

The Bluetooth Mesh Directed Forwarding echo procedure is another timer-driven procedure. The path echo timer is set up at the path origin node when a path has been established. When this timer expires, the path origin sends a PATH_ECHO_REQUEST message to the destination address of the path. The PATH_ECHO_REQUEST is relayed to the path target nodes. On receiving a PATH_ECHO_REQUEST at a target node, a PATH_ECHO_REPLY is sent back to the path origin. Receiving this message at the path origin within a configured time limit validates the path. Failure to receive an echo reply at the path origin invalidates it and causes the path to be deleted from the path origin’s forwarding table.

Path validation using the Bluetooth Mesh Directed Forwarding echo procedure checks that a path is still working.

Subscription Changes

If a Bluetooth Mesh Directed Forwarding node subscribes to a new address, or if a dependent node (see ) such as a low power node subscribes to a new address, then the Bluetooth Mesh Directed Forwarding solicitation procedure is performed. This procedure causes a path to be updated to include this node, which becomes an additional target node in the path.

Self-Organization and Optimization

The monitoring and maintenance procedures ensure that broken paths are identified and re-established automatically. This is an example of self-organizing behavior in a Bluetooth^® Mesh network.

Metrics are used to select the best available node sequences when establishing paths. But as more lanes involve a node, it may cease to be the best option for one or more of the paths it supports. As such, the periodic removal of paths at the end of their lifetime, and their subsequent re-establishment, means that paths and their lanes are always the best available in terms of path metrics. Bluetooth Mesh Directed Forwarding paths are self-organizing and self-optimizing. 

2.2.8 Access Messages

Access messages are message types that are defined as part of client and server models and which act upon the model’s state values. Access messages may be delivered across the network by either Bluetooth Mesh Managed Flooding or by Bluetooth Mesh Directed Forwarding. The Directed Publish Policy state indicates which of the two methods should be used.

All access messages are secured at the network layer using security material which consists of a encryption key and privacy key. The security material used is identified by NID field. A number of different security materials may be generated from the same NetKey using different parameters to the k2 security function. These security materials are used for different purposes. The Bluetooth Mesh Managed Flooding material is used for all messages sent over the subnet associated with its NetKey except for some special cases. For example, the friendship security material is used in securing PDUs exchanged by friend nodes and their dependent low power nodes.

To indicate to relay nodes that Bluetooth Mesh Directed Forwarding should be used, network PDUs are secured by the path origin with security material known as the directed security material.

The formulae for calculating the Bluetooth Mesh Managed Flooding and Bluetooth Mesh Directed Forwarding security materials are as follows:

managed flooding security material

NID || EncryptionKey || PrivacyKey = k2(NetKey, 0x00)

directed forwarding security material

NID || EncryptionKey || PrivacyKey = k2(NetKey, 0x02)

As can be seen, the two formulae vary only in the second parameter value. Function k2 is defined in the Bluetooth^® Mesh Protocol Specification.

2.2.9 Lane Creation vs Lane Use

When an access message is published and Bluetooth Mesh Directed Forwarding selected for the delivery method, all nodes in all lanes in the path may be used. The message is broadcast by the path origin and relayed by each Bluetooth Mesh Directed Forwarding relay node that is on the path and in range, irrespective of the lane it was deemed to be in during path discovery and establishment. Adding lanes really just adds additional nodes to the set of nodes that form and service the path, and when used to deliver access messages, the distinction between lanes ceases to matter. This has a beneficial consequence.

The path creation procedures identify sequences of nodes which can service the delivery of messages from a path origin node to one or more path target nodes. Node sequences are identified in one or more iterations of the discovery and establishment procedures, each executed sequentially. We can imagine each lane as containing distinct sets of node sequences, servicing the same source and destination. But as discussed, when Bluetooth Mesh Directed Forwarding is used to deliver an access message, that distinction ceases to exist. The lanes of the path operate as a single, larger set of nodes which are able to forward a message to its destination. Consequently, there may be more distinct sequences of nodes that might be available when delivering an access message than were explicitly identified during path discovery and establishment.

Figure 11 – Path use in delivering access messages

Figure 11 depicts a path from node A to node J. Two lanes were required, and the discovery and establishment procedures identified the node sequences A/D/E/J and A/X/W/F/G/J. But nodes D and X are in range of each other, so when A publishes a message addressed to J, with Bluetooth Mesh Directed Forwarding to be used, copies of the message may also travel along either A/D/X/W/F/G/J or A/X/D/E/J. This means that there is even greater redundancy and, therefore, even greater reliability afforded by a multilane path than might be apparent at first sight.

2.2.10 Node Dependence

The concept of node dependence describes a relationship between nodes of different types where one node acts as a supporting node and provides a service to one or more other dependent nodes. For example, friend nodes act as supporting nodes to low power nodes, which are dependents in the relationship. A friend node provides a service to dependent low power nodes by acting as a temporary store for messages addressed to them. The low power nodes collect those messages from the friend, at their convenience and consequently conserve power through reduced radio activity.

In version 1.1 of the Bluetooth^® Mesh Protocol Specification, node dependence has become a more broadly applicable concept and may apply to Bluetooth Mesh Directed Forwarding in a number of scenarios. In essence, a supporting node which provides a dependent node with a directed forwarding service will ensure all messages from the dependent node are secured with the directed security material when relayed and will perform required directed forwarding procedures on behalf of the dependent node.

The supporting node’s forwarding table contains a list of the addresses of dependent node elements and acts as the path origin in all Bluetooth Mesh Directed Forwarding operations carried out on behalf of the dependent nodes, including the execution of Bluetooth Mesh Directed Forwarding procedures.

Proxy Nodes and Bluetooth Mesh Directed Forwarding

The proxy function involves a proxy client and a proxy server. The proxy client typically uses the proxy protocol over the GATT bearer to send and receive mesh PDUs to and from other nodes in the network via the proxy server. Proxy clients are often smartphone, desktop, or web applications.

The proxy server implements a GATT service which contains two GATT characteristics, mesh proxy data in, and mesh proxy data out. The proxy client writes proxy PDUs to the mesh proxy data in characteristic and receives PDUs as GATT notifications.

A proxy server may support Bluetooth Mesh Directed Forwarding, and, if it does, this is indicated by the Directed Proxy state being present and having a value of enabled.

How the proxy server behaves may vary from connection to connection, according to a number of parameters. When a proxy client first connects to a directed proxy server, it will receive a proxy configuration message called the DIRECTED_PROXY_CAPABILITIES_STATUS message. This message indicates the Bluetooth Mesh Directed Forwarding parameters that currently apply to the connection and consists of two fields. Directed_Proxy indicates whether or not the directed proxy function is enabled for the proxy server. Use_Directed indicates whether or not Bluetooth Mesh Directed Forwarding will be used for proxy client messages over this connection.

Proxy clients can exercise some control over the behaviour of a directed proxy server by sending a DIRECTED_PROXY_CONTROL message. It includes the Use_Directed field so that the proxy client can inform the proxy server that it should use Bluetooth Mesh Directed Forwarding for messages that this client sends. If the Use_Directed field has a value of enabled, then the message must also include an optional field called Proxy_Client_Unicast_Addr_Range. This field contains a unicast address range for which Bluetooth Mesh Directed Forwarding must be used by the proxy server.

Proxy clients may use Bluetooth Mesh Directed Forwarding directly or indirectly.

To use Bluetooth Mesh Directed Forwarding directly, the proxy client secures messages with the directed security material, indicating to the proxy server that it must act as a directed relay node.

To use it indirectly, the client leverages the service provided by their supporting directed proxy server. Messages are secured with the Bluetooth Mesh Managed Flooding material, and, provided directed relaying is enabled at the proxy server and a path exists to the destination address, Bluetooth Mesh Directed Forwarding will be used by the proxy server for the message on behalf of the dependent client.

Friendship and Bluetooth Mesh Directed Forwarding

Friend nodes may act as directed friends and, in a similar manner to that which was described for proxy nodes, provide a Bluetooth Mesh Directed Forwarding service to associated low power nodes. A friend will act as a directed friend if this function is enabled in the directed control state. If this is the case, the friend node will use Bluetooth Mesh Directed Forwarding to relay messages from its low power nodes when possible and will execute Bluetooth Mesh Directed Forwarding procedures when necessary. For example, if a low power node seeks to send a message to an address for which there is currently no path listed in the friend’s forwarding table, the friend will create an instance of the path origin state machine state and initiate the Bluetooth Mesh Directed Forwarding initialization procedure. To use this functionality, the low power node must use friendship security material for originating messages.

3. Close

The Bluetooth^® Mesh Directed Forwarding feature improves the efficiency with which the shared radio spectrum is used within a network and, in so doing, increases the overall scalability of the network. The automated creation and maintenance of Bluetooth Mesh Directed Forwarding paths makes network planning and configuration much easier.