Bluetooth® Mesh Directed Forwarding
|Document Version :||1.0|
|Last updated :||September 19, 2023|
Martin Woolley, Bluetooth SIG
September 19, 2023
Martin Woolley, Bluetooth SIG
The Mesh Profile Specification has been renamed and is now called the 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 Mesh Profile Specification.
Directed forwarding was introduced in version 1.1 of the Bluetooth® Mesh protocol specification. To fully appreciate the capabilities and benefits of 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 directed forwarding feature.
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.
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
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.
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 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.
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 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 optimising 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.
There are scenarios where more control over precisely which nodes will relay a message than managed flooding can offer would be advantageous. Consider the following scenarios:
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.
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.
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.
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, 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. 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 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 directed forwarding capability which was introduced with the Bluetooth Mesh Feature Enhancements Version 1.1 release.
This section reviews the directed forwarding feature.
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 directed forwarding will ignore any message which it cannot assist in its journey.
Nodes which have the ability to use directed forwarding when originating or relaying messages are called directed forwarding nodes. Those which can relay messages using directed forwarding are called directed forwarding relays. A directed forwarding relay is always a directed forwarding node, but a directed forwarding node may or may not also be a 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 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 directed forwarding node.
Figure 4 – Directed Forwarding
Designing and setting up (commissioning) larger Bluetooth® Mesh networks which use 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 directed forwarding requires little effort when the network is commissioned. All nodes may be configured to use directed forwarding and all they require to work is for a simple set of directed forwarding policy parameters to be set, after which the system will self-maintain and self-optimize the required communication paths.
A new foundation model called the 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 Directed Forwarding state and the Directed Relay state. These states indicate and control whether or not directed forwarding and directed relay functionality is enabled respectively. Given the relationship between these two functions, the directed relay state is bound to the 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 Directed Forwarding Configuration Server model determines whether or not a node has the potential to use directed forwarding. The value of the Directed Control state determines which directed forwarding functions are enabled or disabled.
The selective participation of 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 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 directed forwarding.
The source of a path is always a single node, identified by a unicast address. In the context of 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 directed forwarding, a path has a single path origin node and one or more path target nodes.
A 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, directed forwarding retains one of the benefits of the simpler 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 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 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 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 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 directed forwarding nodes that are not on that path will discard the message. It is clear that 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 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 – Managed flooding
For easy comparison, Figures 7 and 8 are repeated here, side by side:
A path has already been described as a set of nodes that provide a 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.
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. Directed forwarding offers mesh network designers an additional feature with which to assure the reliability of the network. This feature is the multi-lane directed forwarding path.
The directed forwarding feature defines the concept of a lane. A directed forwarding path consists of one or more lanes.
A lane is a set of nodes which can provide a 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 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 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 directed forwarding relays which can deliver a message to its destination. It will, however, generate more overall traffic in the network.
There will often be more than one sequence of 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 directed forwarding. How paths and lanes are created and the role of path metrics in that process will be examined next.
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 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 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 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 Directed Forwarding Initialization, Directed Forwarding Discovery, and 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 directed forwarding initialization by the path origin node. An identifier called the forwarding number is also allocated during 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.
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 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 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 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 – Directed Forwarding Discovery and Establishment
In summary, path discovery involves PATH_REQUEST messages travelling through every possible sequence of 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.
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.
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.
The Path Origin State Machine is associated with a specific 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 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.
The 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 directed forwarding echo procedure checks that a path is still working.
If a 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 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. Directed forwarding paths are self-organizing and self-optimizing.
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 managed flooding or by 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 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 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 managed flooding and 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.
When an access message is published and 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 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 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 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.
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 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 directed forwarding operations carried out on behalf of the dependent nodes, including the execution of directed forwarding procedures.
Proxy Nodes and 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 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 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 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 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 directed forwarding must be used by the proxy server.
Proxy clients may use directed forwarding directly or indirectly.
To use 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 managed flooding material, and, provided directed relaying is enabled at the proxy server and a path exists to the destination address, directed forwarding will be used by the proxy server for the message on behalf of the dependent client.
Friendship and Directed Forwarding
Friend nodes may act as directed friends and, in a similar manner to that which was described for proxy nodes, provide a 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 directed forwarding to relay messages from its low power nodes when possible and will execute 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 directed forwarding initialization procedure. To use this functionality, the low power node must use friendship security material for originating messages.
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 directed forwarding paths makes network planning and configuration much easier.