BLE – A short introduction to the world of Bluetooth Low Energy

When the first Bluetooth Low Energy devices came onto the market, BLE had something almost mystical about it. Everyone wanted to use this technology, even if hardly anyone really understood how it worked. In addition, integrating BLE was hard work back then. To work with BLE, you generally had to be thoroughly familiar with the Bluetooth specification and the stack implementation used. Fortunately, that has changed. With the widespread use of BLE, BLE-enabled hardware has also become increasingly easier to use. Today, there is an extensive list of SoCs and modules that can be programmed with very little effort. Nevertheless, you should have a certain basic understanding in order to select the right hardware and software. In this article, I will attempt to provide a brief introduction for anyone who is new to the topic. I will also attempt to clarify common misconceptions and shed light on the limitations of the technology.

If you would like to delve a little deeper into the world of BLE, I also recommend my further article:

Low latency with Bluetooth Low Energy

This article is primarily about how to achieve the lowest possible latency with BLE. However, to explain this, I'll also cover some basics that are useful for a general understanding of BLE.

Which hardware is suitable for my project?

There's now a wealth of BLE-enabled hardware on the market. Which one is suitable for your project depends on the specific application scenario.

SoC or integrated module

Whether an integrated module or a pure SoC is used depends primarily on the production volume. With high production volumes, the lower costs of the SoC become noticeable. With lower production volumes, integrated modules are characterized by lower development costs. Furthermore, modules with an integrated antenna usually have pre-certifications for specific regions. If an SoC is used, corresponding certification must be carried out for each country. One advantage of SoCs, however, is the ability to design the RF front end and the antenna placement yourself. This can potentially achieve significantly greater transmission ranges.

Country approval for BLE modules

If you choose a fully integrated BLE module with an integrated antenna, you often have the advantage of having the modules pre-certified for the relevant countries. This issue is often considered less important, but it can be crucial if you plan to sell your product in many regions around the world. If you want to offer your product worldwide, you can expect six-figure certification costs. Pre-certifications in the relevant countries offer enormous savings potential here.

However, caution should be exercised when using modules without metallic shielding. These do not receive full certification in the USA and Canada, for example, due to regulatory requirements. In South Korea, pre-certification of modules without metallic shielding is not possible at all. If a module without metallic shielding is used, it is important to consider the implications of this decision for country approval costs.

Pre-installed stack against own Bluetooth firmware

Using a pre-installed Bluetooth stack can save you a lot of trouble. Especially in the medical technology sector, a pre-installed Bluetooth stack offers a significant advantage: It significantly reduces documentation effort. This may not sound like a big deal at first, but it's important to keep in mind that custom Bluetooth firmware represents an additional software project that must be developed and documented in accordance with regulatory requirements. In addition, using a pre-installed stack generally results in significantly lower development costs and eliminates the need for costly IDEs or compilers.

Data rate

This is one of the most misunderstood features of BLE. You often see the value of 1 Mbps, which certainly sounds pretty good. Unfortunately, this value is completely wrong. I'll avoid going too deeply into the BLE protocol at this point. To gain a basic understanding of why 1 Mbps is far from anything you can achieve with BLE (including the new Bluetooth 5.0 standard), you really only need to know the following:

• 1 Mbps is the bit rate of BLE transmitters (2 Mbps is also available for BT 5.0). However, anyone who has ever dealt with any communication protocol should know that there is always a certain amount of overhead involved in the protocol.

• Now you could calculate the net data rate based on the bit rate and the payload per packet. If you did that, you'd still get more than 900 kbps, which still sounds pretty good... but unfortunately, it's still wrong.
• Now, you need to know that the BLE central device and the peripheral device must always communicate alternately. Even if the central device has nothing to communicate, it must send at least one empty packet. There's a gap between each packet. So, assuming one device always transmits the full amount of payload data while the other only transmits an empty packet, you still get around 800 kbit/s when you factor in the gap between the packets. This is what's theoretically possible with BT 4.2. Unfortunately, the reality is usually quite different.
• BLE communication takes place during so-called "connection intervals." During these intervals, the BLE devices exchange data with each other. According to the BLE specification, this connection interval must be a minimum of 7.5 ms and can be increased in 1.25 ms increments. Theoretically, a connection interval can last several seconds. The problem is that all communication must be completed by the end of the connection interval. This means that the recurring sequence of...
• 1. Package Central to Peripheral
  2. pause
  3. Peripheral to Central Package
  4. pause

...must be completed. So, if at a certain point in time there is still room for a packet from the central to the peripheral, but not for the remaining three steps, no further data is exchanged. From this point on, the crystal ball gazing begins. It is difficult to estimate how many bytes will be transferred from the central to the peripheral and when. This depends heavily on the implementation of the BLE stack. Accordingly, it is difficult to predict how many packets can be exchanged in an interval. Furthermore, the maximum number of packets in an interval is limited in most stack implementations.

• In addition, BLE doesn't get along particularly well with other users of the 2.4 GHz frequency band. Its relationship with the ubiquitous Wi-Fi is especially poor. This not only communicates on the same frequency band, but also transmits at significantly higher power. Due to its low transmission power, BLE data is susceptible to interference from other users on the frequency band. If a packet arrives corrupted at the receiver as a result, all further communication within that connection interval is terminated.

Long story short: The BLE data rate is difficult to predict under realistic conditions and is usually significantly lower than 1 Mbps. I think that in a reasonably "clean" environment, a transmission rate of 100 kbit/s is quite reasonable. Higher rates, up to the theoretically achievable 800 kbit/s, are possible. However, one should be aware that such values can only be achieved if one delves deeply into the BLE protocol and the stack implementation used.

latency

This is pretty much the biggest disadvantage of BLE. In the chapter “Data Rate” the so-called Connection Intervals These regulate how often a BLE device can communicate with its counterpart. Theoretically, data can be exchanged throughout the entire connection interval. The problem is: If no data is available at the beginning of the interval, the data exchange for that interval ends after both devices have transmitted an empty packet to their partner. Depending on when Bluetooth data is passed to the Bluetooth stack for transmission, it may take a full interval, plus the time it takes to transmit the data.

This results in a certain degree of variability in latency, making it almost impossible to predict when data ready to be sent will actually arrive at the receiving end. If a data transmission fails, e.g., due to interference from other participants in the frequency band, this variability can increase many times over. The following video shows an example of the latency of a BLE transmission. In this test, data was transmitted to a BLE module at a fixed interval (yellow line). The time delay between when the receiving module forwards the data was then measured (green line). Despite a connection interval of 7.5 ms, the maximum latency was almost twice as high.

In summary, the latency of a BLE data transfer is always subject to a certain degree of variability. The maximum latency can be influenced by selecting the connection interval. Under realistic conditions, however, I wouldn't expect intervals significantly shorter than 20 ms. This is generally acceptable. However, it should be noted that one can never say with complete certainty how long it will take for data to be transferred via BLE. This makes precise synchronization between two BLE devices and real-time data transfer difficult.

BT 4.0 / 4.2 / 5.0 – All the same?

That's basically true. BLE is BLE, after all. A common misconception is that the Bluetooth 4.0 specification only includes BLE. In fact, BLE is simply an extension of the Bluetooth protocol, added since version 4.0 and further developed in subsequent versions. Nevertheless, classic Bluetooth is still included in the specification.

The packet structure and how it is exchanged is very similar for all BLE versions. This makes the standards (partially) backward compatible. Nevertheless, there are significant differences. Here are three of the most important, in my opinion:

1. Secure Pairing: This is arguably one of the most important innovations introduced with BT 4.2. New pairing mechanisms finally made BLE somewhat secure.
2. Packet size: Something has also changed here. With BT 4.2, a BLE packet could contain just 27 bytes of payload data, whereas with BT 4.2, it was already 251 payload bytes. However, it should be noted that with larger packets, the number of packets per connection interval also decreases. Nevertheless, the data rate has been significantly increased, since with continuous data streams from A to B, fewer empty packets are required from B to A (see above). Furthermore, there are fewer pauses that must be observed between each packet.
3. Bitrate: The biggest change in BT 5.0 is that the bitrate is now configurable. Instead of the usual 1 Mbps, 2 Mbps can now be set. Additionally, BT 5.0-enabled devices transmit at significantly higher power, resulting in increased range. However, since the higher data rate results in lower receiver sensitivity, you effectively have two options:
   • You transmit with (almost) double the data rate and similar range as BT 4.2
   • You transmit at the same data rate, but with a significantly increased range

It's also worth mentioning that the higher bit rate can also reduce latency for large data volumes. While the minimum connection interval remains at 7.5 ms, significantly more packets can now be transmitted per interval.

Data security

BLE communication is generally encrypted. Certain data exchanged during pairing is an exception. The security of a BLE connection depends on the pairing mechanism used. BT 4.2 has offered so-called Secure Connections. As the name suggests, these mechanisms have made BT significantly more secure. Therefore, I would advise against using legacy connections, especially in the medical field. Fortunately, almost all BLE devices on the market today support Secure Connections. The difference in the new standard lies in the protocol used to exchange keys during pairing. Since 4.2, the Elliptic Curve Diffie-Hellman (ECDH) algorithm has been used for this, significantly increasing the security of the pairing process.

Unfortunately, security vulnerabilities in BLE devices continue to emerge. However, these are generally less a result of the BT specification and more a result of poor pairing implementation. Therefore, if you plan to use BLE in the medical field, you should consider providing the option to update Bluetooth hardware in case security vulnerabilities become known.

Furthermore, with BLE, not all pairing is the same. Since BT 4.2, there have been four different pairing mechanisms, each offering a different level of security.

• Just Works^TM: As the name suggests, this is a simple but at the same time comparatively insecure pairing mechanism, even though the security of the mechanism has been significantly increased compared to the old BT 4.0 standard.
• Out-of-Band: With this mechanism, a large portion of the data is exchanged during pairing via an alternative connection. This could be a wired connection, for example. It should be noted that this mechanism only offers security if the alternative channel is not being monitored.
• Passkey: With this method, both devices receive a 6-digit code that serves to authenticate the connection. This method has also been significantly improved in the BT 4.2 standard, but still presents a certain risk, especially when static codes are used.
• Numeric Comparison: This method is similar to Just Works^TM, however, offers increased security by adding an additional step at the end of the pairing process. In this step, both devices calculate a 6-digit code, which is displayed to the user on their displays. The user must then confirm on both devices that the codes are the same. This method offers increased protection against attacks but requires the presence of displays on both devices.

Which pairing method is chosen depends on the application scenario and the resulting security requirements. If security-critical or personal data is being exchanged, it is important to carefully consider the respective advantages and disadvantages of the respective mechanisms.

Would you like to use BLE and have questions? We'd be happy to support you. Feel free to take advantage of our expertise here.

Best regards

Björn Schmitz