The Bluetooth SIG has recently released a 2020 Bluetooth® Market Update identifying new trends and forecasts from ABI Research and other analyst firms.
The use of Bluetooth for location is expected to achieve 32% compound annual growth (CAGR):
Obviously, these and other numbers in the report were analysed prior to the coronavirus crisis.
For Bluetooth Mesh, 90% of end-product Bluetooth® mesh qualifications are lighting focused. As with the introduction of iBeacon, which initially focused on marketing messages, the wider capabilities and opportunities are initially not being fully exploited. Part of the problem is that the standard models that come with Bluetooth Mesh are more lighting focused because the standard was driven by individuals from the lighting industry. Custom models, such used by our SensorMesh™, are possible but take more effort.
Protesters in Hong Kong have been using Bluetooth mesh to communicate with one another so as to avoid using the Internet and therefore making it difficult for the Chinese authorities to intercept. However, this isn’t standard Bluetooth mesh as defined by the Bluetooth SIG. It’s a proprietary mesh protocol over standard Bluetooth.
The app used is Bridgefy and there many such peer to peer apps such as FireChat (server has been turned off and no longer works), Signal Offline and Briar that use Bluetooth and WiFi direct.
The use of stand-alone Bluetooth mesh networks isn’t limited to protesters. A growing number of SDKs allow mesh networks to used by companies and organisations. When used with iOS and Android devices (which don’t necessary have to be smartphones) these provide for WiFi-less and Internet-less communication. This allows use, for example, in emergency situations when cellular and Internet goes down. Alternatively, they can simply provide connectivity across a site where there’s no cellular coverage or WiFi.
Wireshark has announced support for the Bluetooth Mesh Beacon, PB-ADV, Provisioning PDU and Proxy Bluetooth mesh protocols.
Wireshark is a protocol analyser that takes packets and decodes into human readable data. It’s usually used with other hardware and software as the last stage in processing captured data. For example, you can use Wireshark with the Nordic nRF sniffer, on Adafruit hardware and on Linux.
In the case of Bluetooth mesh, data packets are encrypted. In fact, data is double encrypted in that first the data is encrypted and then the packets. This means that while you can capture packets you can only see the packet types and Bluetooth mesh metadata. You won’t be able to decrypt the actual data. It’s more useful for determining the type and size of traffic for mesh traffic optimisation.
Friendship allows a low-power IoT device to go to sleep with a separate higher-power node caching packets until the lower power device wakes up. The paper provides an overview of friendship and the Friendship Security Material(FSM) unique to this type of communication.
The researchers found three flaws in the Bluetooth friendship mechanism related to:
The possibility of eavesdropping on communication and selectively jamming based on size of the control messages.
The lack of protection of the friend security keys against an insider attack.
The possibility of misuse of Friend Clear messages to cause a form of denial of service attack through flattening the battery.
The paper includes a reference to tools that demonstrate these problems and discusses possible mitigations.
The Bluetooth SIG responded:
Compromise of the friendship relationship results only in a compromise of the availability of the low power node to the other nodes in the subnet.
It is the conclusion of the working group that the friendship relationship between an LPN and its friend within a mesh subnet is not intended to be secured against attack by a party already in possession of the network key.
It is the position of the Mesh Working Group and the Bluetooth SIG that neither scenario provides additional security risk for a user of the Mesh profile
In other words, the risks are appropriate to the level to which the mesh is expected to be used or attacked.
We have yet to come across any devices using friendship. Friendship is an edge case that isn’t required in most instances. Also, most existing low power devices can’t be upgraded to use mesh due to the higher memory requirement of Bluetooth Mesh.
The paper explains mesh topologies and routing protocols. It describes Bluetooth:
“BLE is presently raising more and more attention and is becoming one of the leading technologies for both IoT-oriented and industrial scenarios”
The authors provide an in-depth introduction to SIG Bluetooth Mesh. (Note that an excellent higher level overview also very recently became available from InsightSIP). The research paper also mentions other Bluetooth mesh implementations such as the draft IETF Bluetooth Mesh for IPv6.
Applications such as smart city, industrial monitoring and smart agriculture are considered and factors such as interoperability and security are mentioned. Finally, the paper compares other protocols such as Thread, ZigBee and LoRaWAN.
There’s an informative video presentation on the Bluetooth SIG web site on Simplifying Multi-Vendor Mesh and Sensor Networks. It provides an introduction to Bluetooth mesh and explains the ways in which it can provide for Industrial IoT (IIoT).
To add to this, Bluetooth Mesh is suitable for use on the factory floor where the environment can be electrically noisy. Standard Bluetooth Mesh uses advertising on several channels rather than (GATT) connections so as to provide for more reliable communication in environments with wireless interference.
Silicon Labs have a useful web site, webinar and slides on “Benchmarking Bluetooth Mesh, Thread, and Zigbee Network Performance”.
The two main measures of performance are throughput, the rate data transfer that can be achieved (in bits per second) and latency, the time taken for data to cross the network.
With a typical implementation of 6+ hops, throughput converges to a similar order of magnitude for all the protocols:
In real use these protocols only support of the order of low thousands of bits (not bytes!) per sec and should therefore only be used for sending small amounts of data that don’t change very often.
For a small payload with 192 nodes, Zigbee has lowest latency and Bluetooth has greatest variation of latency of 20ms to 200ms:
For a larger payload, the Bluetooth latency has a larger range of up to 750ms:
Whether the variation of latency matters depends on your particular solution. Which technology is best depends on what you need to accomplish. For example, in a Bluetooth lighting scenario you might not want some lights to come on immediately and far ones to come on up to a second later. For sensing, the delay usually doesn’t matter.
You also need to consider other factors such as interoperability, scalability, security, reliability and ease of deployment. For example, Zigbee is less scalable and Silicon Labs recommends a maximum of seven hops otherwise the network becomes congested due to re-tries. Bluetooth has especially good interoperability because it is ubiquitous on smartphones and other devices. It also works reliably in industrial situations and has double encryption.
All protocols can be difficult to deploy due to the lack of off-the-shelf general solutions outside specific verticals such as lighting and home automation although our SensorMesh™ is a notable exception.
SensorMesh™ is our technology that allows Standard Bluetooth advertising, such as from beacons, to be relayed across a site using standard Bluetooth Mesh. When used with iBeacon or Eddystone beacons, SensorMesh™ output enables you to determine the location of assets and people to the nearest relay node. When using SensorMesh™ with sensor beacons, you can detect movement, temperature, humidity, air pressure, light, open/closed, close proximity and human proximity (PIR).
We have updated SensorMesh™ to remove the gateway box. It was decided it would be too complex to set up for ISVs. Instead we now have a gateway node that sends output to a USB COM Port.
This widens the possibilities for the receiver to be a PC, Linux box, Raspberry Pi, single board computer or any device with a USB port. For customers who need the data to be uploaded, in place of the gateway box functionality that uploaded to a server, we now have an installable Windows 10 Service that takes data from a COM port and uploads it to your server, BeaconServer™ or BeaconRTLS™.
As previously, SensorMesh™ is stand-alone hardware with no subscription and isn’t software as a service (SAAS). You buy the hardware and then there are no ongoing costs. The data stays within your systems.