Here at BeaconZone we create solutions based on products that use Bluetooth LE. The Bluetooth standards are created and maintained by the Bluetooth SIG. This post briefly explores the advantages and disadvantages of such standards and the opportunities and risks of going off-piste using 3rd party wireless standards.
The main advantage of the Bluetooth LE standard is interoperability. We can use beacons, sensor beacons, smartphones, gateways, single board computers such as the Raspberry Pi, laptops and desktops in solutions and be sure they can communicate using Bluetooth LE. More specifically, we can use the Bluetooth APIs on these platforms and they speak a common language and ‘just work’. Bluetooth has also recently introduced standards on top of the Bluetooth LE standard that provide for mesh networking and angle based location.
The Bluetooth LE standard has caused the ecosystem of System on a Chip (SoC) vendors such as Texas Instruments, Nordic Semiconductor and Dialog Semiconductor to create inexpensive sub-systems and SDKs that simplify implementing new products based on the standards. This, in turn, has created a large variety of devices that can talk to each other even though they use hardware from different vendors. The variety of devices has increased competition, keeping device prices down.
The problem with standards is that they evolve very slowly and might not be optimal for specific situations. This creates an opportunity for 3rd parties to create alternative wireless solutions such as Ultra Wideband (UWB) devices, custom mesh networking and custom location schemes that can provide better performance in aspects such as accuracy, physical range and battery life. These custom products cost more because they are more involved to create/manufacture and their unique features can command a higher price. However, there’s the risk that if/when the companies producing these products go out of business, your solution will become end-of-life with no second sourcing. This is a particular risk when the product involves some sort of software as a service (SAAS), irrespective of standards.
Choosing a wireless technology for your solution involves a trade off between performance, cost and risk. It’s wise to first seek a standards-based and stand-alone (not SAAS) approach and only deviate if you find what you need to do isn’t served by available solutions.
Today’s Bluetooth devices use advertising, GATT connection and mesh. Advertising occurs over three channels to reduce the affects of wireless interference. When more than one device advertises at the same time, the data is lost. However, advertising takes of the order of 1ms so the chance of collision is usually small.
In contrast, BlueFlood uses concurrent transmissions (CT) that purposely synchronise transmissions such that if colliding packets are tightly synchronised and have the same contents, the resulting signal might be distorted, but highly probable that they do not destruct each other. This is used with the Glossy flooding protocol and 40 rather than 3 advertising channels.
CT-based protocols achieve enormous performance gains in terms of end-to-end reliability, latency and energy consumption even under harsh interference conditions
Concurrent transmissions are challenging using Bluetooth because transmissions need to be synchronised down to 250ns. Nevertheless, the researchers show this is possible using standard Bluetooth PHY and commercial Nordic SoCs. They achieved an end-to-end loss rate below 1% and managed to receive the signals on a standard smartphone. While the mechanism was fragile it was found to be viable.
New vulnerabilities, called SweynTooth, have recently been found in Bluetooth LE. The problems aren’t in Bluetooth itself but in software development kits (SDKs) provided by some System on a Chip (SoC) manufacturers.
There are three types of problem that can be triggered by sending particular data to Bluetooth devices: crash, deadlock and security bypass. Only some manufacturer’s SDKs are affected and only some of their SoCs models.
Texas Instruments, NXP, Cypress, Dialog Semiconductors, Microchip, STMicroelectronics and Telink Semiconductor SDKs are affected. The main manufacturer used in beacons in beacons and gateways is Nordic so the majority of beacons are not affected. Nevertheless, there are a few beacon models that use Texas Instruments and Dialog Semiconductors SoCs. Of these, very few use the specific affected SoC models.
The only affected devices we stock are the ABKey01, TON9128, TON9118, TON9108 that use the Dialog DA14580 SoC. You should avoid using these in critical scenarios because they can be caused to crash or deadlock. No beacons are vulnerable to the security bypass vulnerability.
As with all security issues, you have to put the possible attacks into perspective. The vulnerabilities are difficult to exploit in practice and it’s usually much easier to steal a beacon or remove its battery to make it inoperable.
The vulnerabilities are of more concern for critical medical devices such as pacemakers and blood glucose monitors.
Many people come to us asking for “programmable beacons” when in fact they want beacons with configurable iBeacon UUID, major and minor. All beacons allow the UUID, major and minor to be changed, usually via an iOS and/or Android app and sometimes via USB/UART for changing the values, over time, via a program.
Truly programmable beacons are those where the internal software can be updated. The beacon contains a system on a chip that’s small computer running code to implement the beacon functionality. In most cases, the software can be updated via pins on the PCB:
Programming requires use of a programmer:
It can be fiddly to program larger numbers so you use a custom-made jig:
It’s not possible to see and update the existing code in a beacon. Any newly uploaded program has to be created from scratch. This is called emdedded programming, is non-trivial and takes of the order of months. Our SensorMesh™ was created this way.
Inside every Bluetooth sensor beacon is a System on a Chip (SoC) that’s a small computer that runs code. Dialog Semiconductor, the manufacturer of the SoC in some beacons, has just announced the world’s smallest (2.0mm x 1.7mm) and most power-efficient Bluetooth 5.1 SoC the DA14531.
The high level of integration means it only needs six additional electronic components and a power supply to make a complete Bluetooth low energy system. It’s expected to bring SoCs down to $0.50 in high volume.
While beacons tend to be limited by battery size rather than SoC size, the reduced price might bring downward pressure on cost. The small size is of more use in power harvesting/wearable scenarios such as printed Bluetooth sensors, connected injectors, glucose monitors and smart patches.
The AS_NRF51 Flex-BLE (pdf) is an ultra-thin version of Nordic’s nRF51822 SoC wafer-level CSP (WL-CSP), employing American Semiconductor’s ‘FleX™ Semiconductor-on-Polymer™’ (FleX SoP) process to reduce package size to approximately 35µm—roughly half the thickness of a human hair.
The largest component of beacons and Bluetooth sensors is usually the battery rather than the SoC. However, the Flex-BLE version will be especially suited to energy harvested and solar solutions where it will be possible to create very thin beacons that can be invisibly manufactured into products or their packaging.