Analysis of the major Bluetooth technologies, including Bluetooth Classic, Bluetooth Low Energy, and CSRmesh as solution for the last 100m of IoT connectivity.
Bluetooth Classic, also standardized as IEEE 802.15.1 in 2002 and revised in 2005 (although this standard is not maintained anymore), was invented in 1994 as a replacement for RS-232. Bluetooth Classic operates in the 2.4 GHz band and is limited to a small number of eight devices. Because of the following reasons, Bluetooth Classic is not a suitable protocol for IoT applications:
- Bluetooth Classic was designed to provide low-latency wireless peripherals and has evolved to provide high data rates. This is achieved at the expense of power consumption.
- The physical layer (PHY) of Bluetooth Classic only supports long packets (up to 2745 bits of payload) with mandatory channel encoding. This enables higher throughput, however, this is not suitable for resource-constrained devices.
- The protocol stack of Bluetooth Classic has grown in complexity and can typically be 128 kB of code size, which is not satisfactory for IoT embedded devices.
- Bluetooth Classic’s loose specification on the modulation index range does not make it easy to improve the receiver performance in the future. Consequently, Bluetooth Classic has poor coverage, typically less than 10 m.
- With a 3-bit address for piconet space, Bluetooth Classic is limited to having a maximum size of 8 connected devices, which is obviously insufficient for IoT applications.
Bluetooth Low Energy (BLE)
BLE also known as Bluetooth v4.0 or Bluetooth Smart originated from Nokia’s WiBree. Contrary to belief, BLE is actually not compatible with Bluetooth Classic since the physical layer (PHY) has been re-designed. BLE is using a fixed data rate of 1 Mbps and GMSK modulation. BLE uses short packets, and is suitable for low-latency proximity communication. Unfortunately, BLE has the following issues that make it less suitable for IoT applications:
- BLE is operating in the crowded 2.4 GHz frequency band, along with Bluetooth Classic, Wi-Fi, ZigBee, and IEEE 802.15.4. This spectrum crowding will pose a severe reliability challenge to all 2.4 GHz devices, and the problem will only get worse when the number of connected object increases.
- BLE is optimized for low-latency sporadic transmissions and therefore its efficiency degrades dramatically for larger data transfers. With its maximum of 20 bytes application payload size per packet, the gross 1 Mbps data rate of BLE translates into a theoretical maximum transfer rate of 250 kbps, and in practice the actual transfer rates drops below 100 kbps. This opposed to Bluetooth Classic v1.2 that achieves 700 kbps, and v2.1 + EDR reaches 2 Mbps actual transfer rate. An actual transfer rate of only 1/10 of the gross data rate is rather lackluster and translates into poor power-efficiency for such type of data traffic. Although many IoT applications may have a limited data amount to transfer, e.g., for switching off or changing the color of a light bulb, others would still require slightly larger transfers. As a result, BLE is not suitable for IoT applications that require higher data transfers.
- BLE has limited range and extending the network therefore requires a hybrid topology where some client nodes act as server nodes for other star networks. In Bluetooth-specific terminology, this is called scatternet, which yields high network complexity in real deployments. For instance, BLE is essentially asynchronous, such that this hybrid topology (mix of star and mesh) causes increased interference and increased power consumption, even inside a single network.
- Finally, BLE suffers from interference from USB 3.0, and poses a challenge when operating with collocated LTE or WIMAX networks. This is reflected in Bluetooth SIG filtering recommendations. However, workarounds are developed as well.
In February 2014, CSR plc, formerly Cambridge Silicon Radio, announced the availability of their proprietary CSRmesh software. CSRmesh operates over Bluetooth Low Energy (BLE) with the aim to enable mesh topology over the restrictive BLE scatternet topology and to provide direct communication between BLE devices. However, we want to note the following:
- The main advantage of CSRmesh is to allow smartphone connectivity. It is still questionable whether this connectivity should be achieved via direct connection to any device or more simply via a gateway or routers, e.g., Wi-Fi or BLE-enabled routers, or even through cellular if a device is out of range.
- Turning BLE into a mesh-able protocol is not that straightforward. Even if BLE in itself is power-efficient for low duty cycle and small data packets, enabling the mesh functionality would require each device to simultaneously be an observer and broadcaster. This implies that each device would continuously listen for advertising packets, and would then switch to advertising the received data for some period.
- The inefficient use of the radio resources inherent to continuous receive would make it difficult to achieve ultra-low-power consumption in resource-constrained devices. As reported on CSR Forums, there happened to be a current consumption in idle state of around 3mA, which is 100x more than people would expect for a battery powered IoT device. In short, the asynchronous nature of BLE, optimized for low duty cycle / sporadic transmission, seems to offer a challenge for the implementation of a power efficient mesh topology on top of the exiting BLE protocol stack.
- Allowing direct smartphone connection to every device may not provide additional functions. On the contrary, as discussed above it will drain the battery of the device. In addition, it is a potential security threat because there is no gateway with sufficient computing power to filter access and enable strong authentication security.
questions / comments? fire away!