Concepts

FruityMesh is a profile specification of a connection-based Bluetooth Mesh implementation, developed and published by M-Way Solutions GmbH. Our commercial implementation is called BlueRange.

This document explains the basic concepts of FruityMesh and gives an overview of the operation and capabilities. It also explains the life cycle of the mesh network and a mesh device (aka. node). Also, it offers some direct comparisons to the BLE SIG mesh implementation.

FruityMesh is based on the Bluetooth low energy part of the Bluetooth 4.1 Specification and is built on top of the host layer. On-air, FruityMesh physical representation is compatible with existing Bluetooth low energy devices as mesh messages are contained inside the payload of Bluetooth low energy connection packets. FruityMesh adds logic on top of the Bluetooth low energy host layer to automatically build connections with other mesh devices within the same mesh network. As it is implemented on top of the host, just as any normal BLE application would be, it is highly portable between chipsets and fully compatible with other Bluetooth Low Energy devices.

In contrast to the SIG mesh, there is no use-case specific node configuration necessary. There is no concept of relay nodes, friend nodes or proxy nodes as each Node can do this decision based on the FruityMesh Algorithm at Runtime. There is however a concept of a Gateway (Sink) and Asset Nodes (movable nodes with very little battery capacity). Also, leaf nodes (aka. friend nodes) can be used for very specific use-cases. See Device Types for more explanation.

FruityMesh, in opposite to the Bluetooth (SIG) Mesh, uses standard Bluetooth low energy connections. This allows it to be much more power efficient and can also allow all nodes to run with battery power, depending on the use-case. While a SIG mesh node needs to scan at all times to be able to receive messages, FruityMesh nodes have scheduled connections with their connection partners. This has the other advantage that the mesh throughput is multiple times higher for FruityMesh nodes.

FruityMesh targets both simple control or monitoring applications as well as sensor data collection or asset tracking. It is a better solution than the SIG mesh once a higher throughput or battery efficiency is required. Is can be used for lighting and automation as there is often the need to collect sensor data in the same network or combine it with asset tracking.

Per specification, FruityMesh supports up to 1999 nodes in one network, with a maximum network diameter of 1000 hops.

The FruityMesh algorithm builds a connection-based network graph that is a tree. It guarantees, that each node is connected to this network if the node can reach at least one node that is part of the network. Each node can send messages to any other node within the network because every node can relay messages in the network tree. Because the algorithm guarantees that there are no circles in the connection-based network, messages do not need a time to live.

Using MeshAccess Connections (similar to the GATT Proxy in the SIG mesh), it is possible for non-mesh devices, such as Smartphones to connect to a mesh network. This can also be used to set up connections between a mesh and a node of a different mesh.

Each FruityMesh node will allow standard BLE connections if it has free resources. This means, that any legacy Bluetooth Low Energy device has the possibility to connect to the mesh by either using the MeshAccess connection protocol or by implementing a custom connection type. This is similar to the SIG mesh GATT proxy, but doesn’t interfere with the mesh in a similar manner as it can be scheduled much better together with mesh activity. The MeshAccessConnections provide security and can be used with a number of different keys. More information about connecting to a mesh network can be found in the documentation of the MeshAccessModule.

FruityMesh supports a number of different device types for different use cases. Most of the time, the default STATIC device type should be used. It is expected that static nodes remain at a fixed position. If these nodes are moved by a significant distance, the algorithm will need to reconfigure the connections, which will result in an instable mesh at the time of moving.

Another use-case is that there is a core network of static nodes and some nodes (such as e.g. sensors), that might be moved around. The moving nodes should be configured as LEAF nodes. They will then not relay messages but will be connected to by one of the static nodes. The static nodes serve as the backbone of the network. Care must be taken that the number of leaf nodes is not higher than the number of static nodes in an area as the static nodes have a limit of connections. This could cause a situation in which some leaf nodes are not connected to the network.

If there is a high number of moving nodes, these should be configured as ASSET nodes. By default, they will only send data to the mesh using broadcasts, but they are also connectable using MeshAccess Connections. The asset will broadcast once it has data that it wants to deliver to the mesh. Setting up the MeshAccess Connection needs to be implemented in a MeshGateway as this is something that needs to be centrally scheduled.

Last, there is the SINK device type. This is also considered to be a static node and something also referred to as a MeshGateway. A special Node Id is assigned to all connected sink nodes and messages to this node id are only received by devices configured as sink nodes.

The FruityMesh addressing scheme is similar to the SIG mesh addressing:

There are more address types available and documented here: Node Ids

Just like Bluetooth Mesh communication is structured into models and elements, communication within FruityMesh is structured into modules. The idea is very similar to the SIG Mesh: communication is structured, so that new components can easily be created and are interoperable.

Each module has a purpose and a known address (moduleId) within the network. We can then send messages to this module and it will process them if they are understood. If not, they will be ignored.

Currently there are few generic modules that ease development of FruityMesh based applications. These are part of the standard, e.g. the StatusReporterModule or the EnrollmentModule and have a well defined set of messages. You can find the full list of FruityMesh modules here.

This documentation is often referring to the term enrolling which is essentially the same as provisioning. Those terms are referring to the same actions of adding node to a network.

Before a device can participate in a mesh network, it must be provisioned. During provisioning, a device is added to the network by assigning a NodeId, the NetworkKey and a number of other optional keys. The provisioning is done by a Provisioner, which is a trusted device with access to the full list of devices in the network. FruityMesh enables provisioning through mobile apps or Gateways, such as the SIG mesh. In addition to that, provisioning over the mesh is also possible. This allows us to provision whole buildings with a single provisioner that does not need to move around. A more detailed description can be found in the EnrollmentModule documentation.

FruityMesh employs several security measures to prevent third-party interference and monitoring. Each device is flashed with a unique and cryptographically secure 128bit NodeKey (Device Key). This key is used to set up a secure connection with the provisioner and is transmitted out of band, e.g. by using a QR code. A less secure option of initially enrolling nearby devices without the device key is also supported and can be enabled. After provisioning, the node possesses a NetworkKey that is used to encrypt all communication in the mesh.

Optionally, a UserBaseKey and an OrganizationKey can be given during enrollment. These keys can be used to authenticate multiple users and to decrypt information from assets that move within an organization. The different key types are documented here.

Both mesh connections and MeshAccessConnections use AES encryption and are protected using a MIC and a nonce from replay, man in the middle, known plaintext or other known attacks.