Enabling Ubiquitous IoT Connectivity with Bluetooth^® Mesh Networking

Bluetooth BR/EDR technology was originally developed for a short-range wireless point-to-point connectivity between mobile phones, tablets, PCs, and accessories like Bluetooth headsets, keyboards, and mice. Since its introduction, this technology has been constantly improved and enhanced, but it has also become the de facto wireless technology for voice and audio streaming and use cases like wireless speakers, wireless headphones, and in-car infotainment.

The Bluetooth BR/EDR technology was however not optimized for low power applications and use cases like sports and fitness sensors, wearable devices and low-power PC accessories. To address these markets, Bluetooth SIG developed Bluetooth low energy technology, which enables short burst wireless connections and data broadcast. Since the introduction, Bluetooth LE was quickly adopted by smart phones and tablets and it enabled new markets and applications like wearable devices, sports and fitness sensors, and beacon applications.

Bluetooth LE technology is still based on point-to-point, star, or broadcast-based network topologies. However, Bluetooth mesh changes that because it allows Bluetooth devices to be used as a true mesh networking topology. This paradigm change for Bluetooth will fundamentally open up a lot of new use cases for Bluetooth developers, which means great innovation in the industry. Bluetooth mesh allows moving away from the typical personal area network, which Bluetooth is known for and extending both the range and number of devices a Bluetooth network can have. A smart home is a great example and use case for Bluetooth mesh as a smart home can easily have 30-50 devices in it and they are not necessarily in the direct range of each other. With Bluetooth mesh, you can network all these devices into a single Bluetooth network and have the entire home coverage for your Bluetooth network. What's really exciting is that Bluetooth mesh nodes can still support the existing Bluetooth LE topologies and use cases like point-to-point connectivity and Bluetooth beaconing, which allows smart phones to be connected to the Bluetooth mesh networks to control and monitor the Bluetooth mesh nodes as well other uses cases, such as indoor positioning and asset tracking.

The Bluetooth SIG released the 1.0 version of the Bluetooth mesh specification that is available to everyone for development. This white paper discusses the key features and capabilities of Bluetooth mesh technology and what new existing use cases it enables for Bluetooth developers.

Figure 1: Bluetooth Technology Flavors and Use Cases

Introduction

This chapter contains a brief introduction to the Bluetooth mesh standard and introduces layers of the Bluetooth mesh stack and the most important features and functionality of each layer. However, the application layer as well Bluetooth mesh security are described separately later in this white paper as they deserve their own sections.

Bluetooth Mesh Architecture

The figure below illustrates the architecture of both Bluetooth LE and Mesh technologies as well the supported network topologies. As shown in the figure, Bluetooth LE and Bluetooth mesh share the same RF and link layer but at the upper protocol stack layers differ significantly.

Figure 2: Bluetooth LE + mesh Architecture

Bluetooth RF and PHY

Bluetooth mesh uses the Bluetooth 4.0 1M LE GFSK PHY and link layer to communicate, which means that Bluetooth mesh can be implemented on top of any Bluetooth 4.0 low energy-compliant radio by adding the necessary software layers on top of it. Currently, Bluetooth mesh does not use Bluetooth 5 features, such as the LE Coded PHY or advertisement enhancements, but this may change in the future versions of the Bluetooth mesh specification.

Bearers

Bluetooth mesh can be used either over an advertising bearer or a GATT bearer. In a typical Bluetooth mesh network, nodes use the advertising bearer to communicate with each other. The advertising bearer uses the Bluetooth LE non-connectable advertisement messages to broadcast messages to all nodes in range. The advertising bearer can contain up to 27 octets of payload and uses its own advertisement data type. The GATT bearer, on the other hand, is used to send and receive Bluetooth mesh messages over point-to-point connections using Bluetooth LE GATT-based services. The GATT bearer enables non-native mesh devices, such as smart phones and tablets to communicate and participate in Bluetooth mesh communications. Bluetooth mesh 1.0 defines two GATT services that Bluetooth mesh devices can use, as follows: 

• Provisioning service, which is used to provision un-provisioned devices into a Bluetooth mesh network
• Proxy service, which is used to exchange Bluetooth mesh messages over GATT connections

Bluetooth Mesh Nodes and Features

A Bluetooth mesh network can consist of different types of nodes where not all nodes need to be equal. As discussed earlier, some nodes relay messages while others do not, and some nodes can be battery operated low power nodes. This section provides a short overview of the different features Bluetooth mesh nodes can implement. First, all Bluetooth mesh nodes can receive and send messages and all Bluetooth mesh nodes must implement the Bluetooth mesh security and the essential mesh models needed for configuration. However, outside these features, the rest of the node functionality is optional.

Figure 3: A Bluetooth mesh Network

Relay Feature

Nodes with the relay feature are capable of relaying messages from other nodes and are essential in increasing the scale and range of a Bluetooth mesh network.

Proxy Feature

Proxy node is capable of acting as a proxy between the Bluetooth mesh nodes and network and a device that only implements the GATT bearer, such as smart phones today. This means proxy nodes must implement both Bluetooth LE and Bluetooth mesh stacks and are the only nodes in the mesh network that must do this.

Low Power Feature

Nodes with low power feature can spend most of their lifetime in a low power sleep mode and only need to wake up and participate in the Bluetooth mesh network communications once every four (4) days, which means their duty cycle can be almost zero. Nodes with the low power feature however need a node with a friend feature, which caches any messages targeted to the low power nodes while they are sleeping. When low power nodes are provisioned to the mesh network, they search for a nearby friend, agree on a communication interval with the friend when they will poll for messages, and after that they can go to sleep.

Friend Feature

Nodes with the friend feature must implement an additional message cache they use to cache messages for the nodes with low power feature and store them until low power nodes wake up and fetch the messages. Nodes with friend feature can also acknowledge messages on behalf of low power nodes, while they are sleeping. Nodes with friend features also advertise their capabilities using special beacons, so low power nodes can select the most optimal friends to associate with. The table below summarizes the Bluetooth mesh node features, but it is possible to combine features, so a node can have multiple features like Relay, Proxy and Friend features.

Network Layer

The Bluetooth mesh network layer handles the basic network message transfer, node and group and broadcast addressing, as well as network level security.

Addressing
The network layer also handles addressing. Bluetooth mesh uses multiple address types, which are explained in the table below. The addressing scheme is different than the Bluetooth device addresses used for Bluetooth LE communications.

Every Bluetooth mesh node is assigned a unicast address for each of its elements during the provisioning process, which is discussed later in this white paper. The group and virtual addresses are, on the other hand, assigned during the configuration of Bluetooth mesh nodes and networks, which also is discussed later.

The figure below illustrates different types of Bluetooth mesh messages from unicast, to multicast (or group), and broadcast messaging. Yellow color is used to indicate the nodes the message is targeted to.

Figure 4: Bluetooth mesh Message Types

Network PDU

The format of the Bluetooth mesh 1.0 network PDU is described below.

Relaying Messages

Next, the network layer relays the mesh messages between the nodes in a network. Wireless mesh networks relay messages in different ways, from IP-based routing algorithms to simple flooding techniques. Bluetooth mesh standard adopted the managed flooding technique as the message relaying algorithm.

Using a flooding message relay in a wireless mesh network offers multiple benefits. It is simple to implement in a resource-constrained device, it recovers from power outages fast as the routing tables do not need to re-built, and can also be very reliable as it inherently provides a multipath message delivery not dependent on single routes or nodes. Finally, it can also easily react to dynamic situations as the nodes do not need to maintain and update routing tables.

However, flooding mesh has drawbacks as well and multiple issues can occur in a flooding mesh network. The typical issues in a flooding mesh network are message looping where messages get relayed in the network forever, scalability and performance issues if the network spends most of its time relaying duplicate, and finally power consumption that is needed to operate the relays.

To address the concerns mentioned above, Bluetooth mesh uses managed flooding to relay messages, which is a hybrid implementation between a fully flooding network and a routing network. The following mechanisms are implemented by the Bluetooth mesh standard to address the issues of pure flooding mesh networks.

Time-to-Live Counter

Every Bluetooth mesh message carries a time-to-live (TTL) counter, which defines the number of times the message can be relayed before it expires. TTL is decremented by one upon reception and the message is relayed if its TTL is still nonzero. The TTL counter is used to prevent the Bluetooth mesh messages from living forever in the network and improve the network performance. Messages can also be sent with TTL value 0, which means they are not relayed at all but effectively only live over a single hop.

Message Cache

All Bluetooth mesh nodes implement a message cache, which is used to store the recently seen or relayed messages. If a node with relay feature receives a message with a large enough TTL, it will check if this message has already been seen or relayed and if it is, the message is dropped again to improve the network performance and reduce traffic.

Relaying Feature is Optional

Bluetooth mesh nodes can implement multiple features, but many of these features are optional, relaying being one of them. This means not every node in a Bluetooth mesh network needs to be a relay, but especially in very large Bluetooth mesh networks relaying can be disabled on most nodes. This approach has two benefits. First, it reduces the network traffic and improves the performance and scalability of large Bluetooth mesh networks and also reduces the power consumption on the non-relaying nodes as they do not need to retransmit the network messages. The next figure shows on example of a Bluetooth mesh network and how a message could travel from a source (S) through relays (R) to a destination node (D).

Figure 5: Bluetooth mesh Relaying

Low Power Feature

Some of the Bluetooth mesh nodes can also implement a low-power feature enabling them to spend most of their life time in a low power sleep mode and keep the radio turned off. These devices typically are battery powered devices, such as light switches or battery-powered sensors. The low power nodes do not relay messages at all. Instead, they only transmit messages when necessary and receive messages upon previously configured intervals. Low power nodes require a friend node to cache messages for them when they are sleeping, which is discussed in more details later.

Network Transmit Count and Transmit Interval

Because the mesh advertisement bearer is inherently unreliable and messages can be lost for example due to RF interference, the Bluetooth mesh network layer implements a network level retransmit feature. The network transmit count only affects messages originating from a node; there is a separate configuration option for relayed messages. The messages are sent using the same sequence number, so at the receiving end the duplicates are dropped because of the message cache.

The transmit count is configurable between 1 and 8 transmissions per network PDU. The network transmit interval defines the delay between the consecutive network PDU transmissions in steps on 10 milliseconds. In addition, the Bluetooth mesh specification requires that every network transmit interval is perturbed by a random 0 to 10 millisecond delay, so the minimum transmit interval is in the range of 10-20 ms.

Figure 6: Network Level Re-Transmit

Relay Retransmit Count and Retransmit Interval

The network level relay retransmit allows the Bluetooth mesh nodes with relay feature to relay the messages they receive multiple times instead of just sending them once. The retransmit count is configurable in a mesh node from 0 to 7 retransmissions. The interval parameter is defined the same way as in the network transmit use case.

Transmit count

Note: The packet RX, processing, and TX overhead is not taken into account in the above calculations and the calculations assume an average 5 ms random delay.

Network Security

The network layer also implements the mandatory network level security, which is discussed more in the dedicated security chapter.

Lower Transport Layer

Because of the limited 31 byte payload of Bluetooth advertisement packets, Bluetooth mesh packets have a relatively small payload and a single network level PDU can only contain up to 16 octets of the network layer payload. However, some applications do require larger messages to be sent and therefore the Bluetooth mesh protocol implements a transport layer. The main task of the transport layer is the segmentation and re-assembly of larger application layer messages into multiple PDUs as well the acknowledgement and re-transmission of any lost messages. Any messages that fit into a single lower transport layer PDU are called un-segmented messages and they are sent from source to destination as a single message. These messages are sent using a best effort mechanism and no acknowledgement is provided to the source if the message has reached its destination or not. Note that it is also possible to “force segmentation” even for single-segment messages if an acknowledgement is required.

Figure 7: Un-Segmented Message

Any application message that does not fit into a single PDU must be fragmented and sent over in multiple PDUs and also re-assembled at the receiving end. These are called segmented messages and they can be up to 380 octets long. Segmented messages are acknowledged by the destination, so that the sender can re-transmit any lost segments and guarantee the message delivery. Bluetooth mesh uses a block acknowledgement scheme to acknowledge the segments which have been received and only the un-acknowledged segments are re-transmitted.

Figure 8: Segmented Message

When using segmented messages, the transport layer has a re-transmit timeout after which any non-acknowledged Bluetooth mesh messages will be resent because they are considered lost. The formula to calculate the re-transmit timeout is as follows:

TTL x 50 ms + 200 ms

For example, when using TTL value of 5, the re-transmit timeout would be: 5 x 50 ms + 200 ms = 450 ms.

Upper Transport Layer

The upper transport layer has few main uses in Bluetooth mesh, as follows. First, the upper transport layer is responsible for the second level of security at Bluetooth mesh, which is the application level authentication and encryption.The upper transport layer is also responsible of control messaging, which is used to establish and manage friendship between low power and friend nodes and manage network health and topology with heartbeat messages.

Access Layer

Access layer defines the format of the Bluetooth mesh application layer (Mesh Model) messages. The access layer messages contain the mesh model ID, which is either 16-bits for Bluetooth SIG standardized models and 32-bits for vendor-specific models. It also indicates whether the message is a client or server message and also contains the opcodes of the message.

The mesh models at the access layer can use unreliable messages that do do not provide a response or reliable messages, which are always provided a response. When reliable messaging is used, the messages must be idempotent meaning that the same message can be received multiple times without changing the result beyond the initial application.

Bluetooth Mesh Security

This section provides a short overview of Bluetooth mesh security and most important security features in the Bluetooth mesh standard.

Security Is Mandatory

The use of security is mandatory with Bluetooth mesh and cannot be disabled to prevent the use of unsecure network in real life applications. Every device added to the network must be given security keys for all network, application, and device management operations and every packet sent in a Bluetooth mesh network must be authenticated, encrypted, and obfuscated.

Dual Layer Security

Bluetooth mesh uses a dual layer security model, where two fully independent security levels are used first at the network level and then at the application level. The network level security is used to authenticate and encrypt all communications within a Bluetooth mesh network and all nodes participating that network.

The application layer security is, on the other hand, used to authenticate and encrypt all application level communications and there can be multiple applications used within a single Bluetooth mesh network. The benefit of this is, for example, that a Bluetooth mesh network can have a lighting application and a separate beaconing application and because they use a separate security domains, the application controlling the lighting cannot control the beacons and vice versa.

Security Starts with Provisioning

The security setup and configuration starts with the provisioning process where a un-provisioned device is provisioned into a Bluetooth mesh network.

Authentication and Establishing a Secure Session

1. Both the provisioner and the un-provisioned device have an elliptic curve key pair (public and private keys). 
2. At the beginning of provisioning, the devices exchange the public keys with each other.
   • Device’s public key can be shared in-band (over Bluetooth) or out-of-band for man-in-the-middle attack protection.
   • Provisioner’s public key is always shared in-band.
3. Next, both devices compute an Elliptic Curve Diffie-Hellman (ECDH) shared secret.

The authentication of devices can be done multiple ways, as follows:

• Dynamic authentication data can be exchanged out-of-band for example by user input (e.g., one device displays a numerical code and the user keys types it on the other device).
• Static authentication data (up to 128 bits) can be delivered out-of-band.
• Additionally, random numbers generated on the fly are used to further protect authentication.
• No authentication data (all zero) is also a possibility.

After authentication is done, both parties generate a session key from the shared ECDH secret and the authentication data and it’s used to protect the rest of the provisioning process.

Network Layer Security

Over the secure session, the provisioner provides the device with a 128-bit AES key for the network the device is added to. The provisioner may later give additional keys to the device. The network key is actually never directly used, but the network level encryption and other security keys are derived from the network key using an AES-CMAC hash. At the network layer, the PDU contains one byte in plain text format identifying to which network the message belongs to and which key should be used, but rest of the PDU is either obfuscated using AES-ECB or encrypted using AES-CCM as shown in the figure below.

Figure 9: Bluetooth mesh Network PDU

Obfuscating the headers makes it harder to perform passive eavesdropping to understand the Bluetooth mesh network structure and messages being transmitted. Message integrity is protected with the 32- or 64-bit network MIC at the end of the PDU. Replay attack protection on the other hand is provided using a changing sequence number (SEQ), which the nodes keep track of and use to drop replayed messages.
 

Transport Layer Security

The transport (or application) layer provides the second layer of security in Bluetooth mesh. A 128-bit AES key, derived from the application key, is used at the upper transport layer to authenticate and encrypt the access leyer PDUs as shown below.

Figure 10: Bluetooth mesh Transport PDU

As mentioned, different applications can use different keys to separate the applications from each other. The access layer key is bound to the Bluetooth mesh models used by the applications to communicate with each other.
 

Device Security

Finally, a third pair of keys is generated called a device key, which the provisioner uses for future device management operations such as changing device settings or handing it new network or application keys. The device keys are never transmitted over the air, but generated and stored locally both at the device and the provisioner.

 

Provisioning, Configuration and Node Life-Cycle

The life cycle of a Bluetooth mesh node starts as an un-provisioned device meaning it has not been added as a part of any mesh network nor has it been configured to operate in a network. The process of adding such a device as part of a Bluetooth mesh network is called provisioning and the process can be done for example using a smart phone application or during production time when devices are manufactured and firmware gets installed. An un-provisioned Bluetooth mesh device may send Bluetooth LE advertisement packets, which announce that it supports the GATT provisioning service. The GATT provisioning service allows a Bluetooth LE device with provisioning capabilities to establish a connection to the un-provisioned device and start the provisioning process.

In addition or alternatively, the un-provisioned mesh device can start sending un-provisioned mesh beacons allowing another Bluetooth mesh node with provisioning capabilities to provision it over the mesh bearer. In Bluetooth mesh 1.0 specification, the provisioning can only be done over a single hop, but future version of the specification may allow devices to be provisioned also over multiple hops making this feature much more versatile. The Bluetooth mesh device provisioning is a secure process in which the provisioner typically performs the following actions:

• The provisioner assigns the device a network key used for authenticating and encrypting the mesh communications. They key is transferred to the device being provisioned in an encrypted format. 
• The provisioner assigns a unicast address for each individual element the device has.
• During the process, device-specific keys are also generated both at the device and the provisioner and they are used for any future device management or configuration operations. The device-specific keys are never sent over the air, but they are generated and stored locally. Once the above steps have been made, an un-provisioned Bluetooth mesh device becomes a mesh node.

Figure 11: Life-Cycle of a Bluetooth mesh Node

The typical next step after device provisioning is device configuration. This again can be done by the provisioner, such as a smart phone application. To ensure that the mesh node is operational in a Bluetooth mesh network, the following steps are typically needed:

• The Device Composition Data (DCD) is read from the mesh node. The DCD contains the models supported by the device, the manufacturer information, and information which features (proxy, relay etc.) are supported by the node.
• Depending on the node capabilities, certain node features (proxy, relay etc.) can be enabled or disabled.
• The network settings, such as addresses and time-to-live counter values are configured.
• One or more application keys are generated and assigned to the node depending on the applications the node needs to support.
• The publish and subscribe, which is discussed in the next chapter, configuration is defined indicating to which groups the node sends messages to and which group messages it listens to.

The configuration of a node can be changed any time during its lifetime.

A Bluetooth mesh node may need to be removed from a Bluetooth mesh network at some point, for example, when a broken device is replaced, devices gets stolen and so on. Bluetooth mesh network management operations provide two ways of removing a Bluetooth mesh node from the network, as follows:

1. A node can be informed that it will be removed from the network, so it can behave accordingly, but this operation should not be used as an only node removal process. Instead, the node removal from the list operation described below should be done to securely remove a node from a network.
2. A key refresh operation can be performed in the whole network meaning every other node in the network is assigned with new network and application keys except the node to be removed. This operation is a heavier process but guarantees the node to be removed is removed from the network.
   

Publish and Subscribe

Bluetooth mesh nodes are typically grouped into logical groups, such as kitchen or bedroom and they are many times also controlled as groups. This grouping of nodes is typically done at the time of provisioning or configuration, as explained in the previous chapter. During this process, the groups are created and nodes are assigned into one or multiple groups.

The mechanism used to setup how the nodes communicate with each other is called publish and subscribe. Sending messages is called publishing and receiving messages is called subscribing. For example when a light switch wants to control the lights in a kitchen, it publishes a message to the kitchen group, to which all the kitchen lights have subscribed to.

Each publish and subscribe group have their own group or virtual addresses and the nodes either send messages to these addresses and receiving nodes listen to the messages send with these addresses. It is possible for a single node to publish or subscribe to multiple groups The figure below illustrates how publish and subscribe could be setup in a Bluetooth mesh network.

Figure 12: Publish and Subscribe

Using publish and subscribe has multiple benefits, as follows. First, it’s easy for humans to understand the concept of groups and assign devices to them. Publish and subscribe also simplifies the initial configuration of devices and messaging in a Bluetooth mesh network and most importantly publish subscribe significantly simplifies the life cycle management of mesh nodes. What it means is that when a new Bluetooth mesh node added to a network or an existing node is replaced, only that node needs to be configured with the publish and subscribe settings and rest of the network nodes can remain unchanged and unware of the change. 

Figure 13: Adding New Nodes or Groups

Mesh Model - The Application Layer Bluetooth mesh specification also defines the application layer called the mesh model. The mesh model is defined to enable full interoperability between devices from multiple vendors and to provide a common language for the devices. The purpose of the mesh model is to enable the light switch from vendor A to be able to turn on or off the lights from vendor B without having to change the software on the light switch or bulb.

Bluetooth mesh models generally define three things, as follows:

• States: Devices have states like On/Off. State can be exposed and states can also change.
• Messages: Messages can be used to set, get, or report state.
• Behavior: Defines how a node behaves when receiving messages and when nodes send messages.

Now, let’s give an example of this. As almost all devices can be turned On or Off, Bluetooth mesh model specification defines a generic On/Off model client and server. The general definition for the generic On/Off model definition looks like this:

• States: On = 1, Off = 0
• Messages: OnOff Get, OnOff Set, OnOff Set Unreliable, OnOff Status
• Behavior: If set to ‘1’ then turn On and if set to ‘0’ then turn Off. 

The On/Off model has a client and server sides and the definition is different for the client and the server.
The On/Off server is defined as follows:

• States: On = 1, Off = 0
• Messages: OnOff Status
• Behavior: If set to ‘1’ then turn On and if set to ‘0’ then turn Off. 

And the On/Off client on the other hand is defined as follows:

• States: N/A 
• Messages: OnOff Get, OnOff Set, OnOff Set Unreliable
• Behavior: To turn on a device send OnOff Set (‘1’). To turn off a device send OnOff Set (‘0’) 

As most devices do more than one thing, an important concept of mesh model is an element. An example of such a device is a power strip with more than one socket and each socket being controllable individually. Each controllable socket in the power strip is assigned a unique element and each element can support a unique set of models, so they can be individually controlled.

Each element in a power strip has:

• Unique unicast address: So it can be individually addressed
• A set of models: For independent behavior
• Sequence number: A unique element number

Another important property in the Bluetooth mesh model is state binding, which is used to map the state of one model to a state of another model.

For example, the value ‘0’ of Generic Level sets the Generic OnOff to ‘0’ and vice versa the value a non-zero value of Generic Level sets the Generic OnOff to ‘1’.

Currently, the Bluetooth mesh model specification defines the following models.

• Configuration model: Node configuration, such as security and publish and subscribe 
• Health model: Node and network health
• Generic models: Generic OnOff, Level, Power, Battery, Transition time, Time, Sensor, Sensor settings, Location and, User property and Admin property
• Application specific: Scene, Light, Light control Many of the application specific models actually extend the generic models and for example the Light Lightness model uses Generic OnOff and Generic Level models.

Concurrent Bluetooth LE and Mesh

As mentioned in the introduction, Bluetooth mesh devices can, but do not have to, implement Bluetooth LE functionality.

A device like the figure below has both a full Bluetooth LE stack and a Bluetooth mesh stacks implemented and this device can have full Bluetooth LE capabilities as well full Bluetooth mesh capabilities.

This has a few benefits, as the device can connect to smart phones, tablets and any other devices implementing the GATT layer while the device is a fully functional mash node. This enables new use cases and applications and non-Bluetooth mesh capable devices to interact with Bluetooth mesh nodes.

Figure 14: A Bluetooth Device with LE and mesh Functionality

The downside of the above implementation is that more memory (both RAM and non-volatile) is needed to implement both stacks and functionality and for some devices, especially when cost is a concern, it is possible to just implement LE or mesh functionality, which requires less memory, but of course also provides less functionality. The figure below shows an architecture of a device which only implements Bluetooth mesh. This device can act as a fully functional mesh node with the exclusion of proxy feature and, since it still supports Bluetooth link layer it can also transmit Bluetooth beacons or discover beacons for example for in-door positioning or asset tracking applications.

Figure 15: A Bluetooth Device with only mesh Functionality

Bluetooth Mesh Support on Smart Phones and Tablets

When this white paper was authored, although almost all smart phones and tablets in the market have Bluetooth 4 support, they however do not implement the Bluetooth mesh advertisement bearer, but only support Bluetooth connections and GATT application layer.

This means that the phones are not able to directly communicate with the mesh network over the advertisement bearer, but need one or multiple nodes in a network with a proxy feature enabled to accomplish that. Also, to provision and configure a Bluetooth mesh device to a node, a phone needs to use the provisioning GATT service.

To enable the phones and tablets to provision and communicate with mesh nodes over proxies, a partial Bluetooth mesh stack is still needed on the phone as it still needs to be able to encrypt and decrypt the mesh network and access layer messages, send and receive mesh model messages and understand and other features. In other words, the application on a phone needs to implement all the layers needs for mesh communications, as shown below.

The operating systems on the phones provide the basic Bluetooth LE services, such as RF, Bluetooth LE stack and the GATT layer, but rest of the implementation needs to be implemented, at least today, outside the phone’s operating systems, which means it needs to be part of an application.

Writing a Bluetooth mesh stack for smart phones can be a significant effort, but Silicon Labs for example provides the Bluetooth mesh stack for Android OS and targets to provide it as well for iOS during 2018.

Figure 16: Bluetooth mesh Architecture on a Phone

Conclusions

Bluetooth mesh 1.0 is a new standard available from Bluetooth SIG since July’17. The standard enables large device networks and many-to-many communications for Bluetooth LE technology, which was not possible with the earlier versions of the specification.

Bluetooth mesh provides a full stack solution, with everything from the RF to application layer defined, which enables us to build truly inter operable devices. Bluetooth SIG has also a long track record of building certification processes, tools and interoperable standards and Bluetooth mesh should be no different.

One of the key differentiators of Bluetooth mesh is the dual-layer security architecture and the security architecture overall as it provides state-of-the art security using FIPS or NIST approved algorithms and authentication of devices with man-in-the-middle protection, authentication, encryption and privacy protection for each message sent as well secure provisioning and network management operations.

Bluetooth mesh inherently also supports Bluetooth LE functionality enabling Bluetooth mesh nodes to connect to other Bluetooth LE devices, transmit beacons for point-of-interest of indoor positioning applications, and scan beacons (assets) for indoor positioning solutions. This features make Bluetooth mesh also unique compared to other similar technologies and enable new applications and use cases being deployed into mesh connected applications like connected lighting, home and industrial automation.

Bluetooth mesh is still a new standard and active development is ongoing at Bluetooth SIG’s mesh working group during late 2017 and 2018 to further enhance the capabilities, performance and usability of Bluetooth mesh so this is just a beginning.