Low latency with Bluetooth Low Energy

Bluetooth Low Energy (BLE) has become the communication standard for low-power wireless communication in recent years. In its early days, BLE was primarily used in consumer applications. However, we have observed in past projects that BLE has now also entered the world of medical devices. Its use in body-worn sensors is a natural fit, as battery life is usually crucial for the sensor nodes used in these applications. However, we have observed that increasingly critical signals are also being transmitted via BLE. One parameter in particular is often in focus: The latencyWhen I speak of latency in this article, I mean the time delay between the first attempt at transmission (passing the message to the BLE stack) and the reception of the message by the connection partner (passing the message from the BLE stack to the application).

This article discusses:

• What causes latency in BLE communication?
• Which parameters influence latency?
• What latency can I achieve with BLE?
• What are the disadvantages of latency-optimized BLE communication?
• How do I deal with latency in safety-critical areas?

If you don’t have much experience with BLE, I recommend taking a look at an older blog article of mine:

https://medtech-ingenieur.de/ble-ein-kurze-einstiegshilfe-in-die-welt-von-bluetooth-low-energy/

Here we'll discuss some basics of BLE. Since we'll be delving into BLE in depth in this article, it's recommended that you familiarize yourself with the basics beforehand.

Since the topic of latency is somewhat complex, this article is quite long. I've tried to highlight the most important points. So, if you're short on time, you can focus on the highlighted text first.

However, if you want to understand why a certain setting should be made, you unfortunately have no choice but to read the entire article.

Why should I even care about the latency of BLE connections?

I know many very interesting articles that deal in depth with the topic of data throughput in BLE. However, I know of few articles that address latency optimization. Optimized latency doesn't necessarily lead to high data rates, and vice versa. Especially in safety-critical areas like medical technology, little data is transmitted. The time it takes to transmit a single message is often crucial. Let's imagine the following (admittedly very far-fetched) scenario:

A defibrillator is to be controlled via a wireless remote control. The remote control has a button that the attending physician can use to deliver a shock. The button should, of course, only be activated when the defibrillator detects a shockable rhythm in the ECG. To signal this to the user, an LED is used to indicate when the button is active.

The crucial point is that in this application, the entire ECG, including all raw data, does not need to be transmitted to the remote control. A high data rate is therefore not required from the defibrillator to the remote control. The remote control only needs the information that it needs to turn the LED on or off. In the other direction, the remote control only needs to send the defibrillator the message "button pressed." This information is not very complex and therefore does not require a high data rate. In both cases, however, latency plays a major role. If either piece of information is delayed, patient treatment is delayed, resulting in valuable time being lost. As already mentioned, the example described is not necessarily useful, but is intended to illustrate why latency is sometimes more important than data rate.

What causes latency in BLE…

To understand the problem with BLE and latency, we should first look at what makes BLE "low energy" in the first place. Unlike classic Bluetooth, BLE connections are never "constantly open." This means there is no constant data stream between A and B. Instead, A and B establish and terminate their connection at specific intervals. These intervals are called "Connection Intervals" (CI)..

Within a CI, the central and peripheral devices can exchange data. Even if no data is to be exchanged, the central and peripheral devices always send at least one empty packet to signal to the other that they are still present. If neither partner has anything else to say, communication is terminated until the end of the CI. In this case, both devices must wait until the next CI before they can send data again. By breaking the connection, BLE's power consumption is significantly reduced. At the same time, however, this behavior means that at least one CI of latency must always be expected. In the example described above, let's assume that a shockable rhythm is detected at the beginning of a CI. The defibrillator therefore wants to send the command to activate the LED on the remote control as quickly as possible. However, if the connection has already been terminated by the central device, the defibrillator must wait at least one CI before it can send. CIs can be configured for each connection but cannot be less than 7.5 ms.

You must therefore expect a minimum latency of 7.5 ms in any case!

It's also important to note that BLE messages aren't simply lost in noisy environments. If packets are damaged during transmission or don't arrive at all, they are always retransmitted. This occurs in the lower layers of the BLE architecture (link layer). Therefore, it's not messages that are repeated, but rather the physical packets. These are retransmitted until they either arrive successfully or the connection is interrupted by one of the two participants. The problem with this is that if a disruption occurs, no more data is exchanged until the next CI. Due to the BLE frequency hopping method (more on this later in the article), each CI operates on a different frequency, so the probability that a packet will arrive at some point is quite high. In practice, however, several retransmissions occur in succession. For this reason, messages can be delayed by several CIs. With two retransmissions, it can be assumed that it takes 3 CIs (i.e., 22.5 ms) for the message to be received. Based on the retransmissions, we can say:

When we talk about latency in BLE, we're only talking about the minimum latency. There's no guarantee that latency will be below the maximum. We can only reduce the likelihood of high latencies occurring.   

This is a bit sobering, but in the coming chapters I will explain how to at least keep the minimum and average latency as low as possible.

How can latency be optimized?

The connection interval

As described above, the CI largely determines the minimum latency of the connection.

If the hardware used and the BLE stack allow it, the connection interval should be set to 7.5 ms.

On smartphones, for example, the smallest CI is usually significantly higher than 7.5 ms.

Slave Latency

Another crucial parameter is the so-called Slave Latency (SL). This determines the number of CIs during which the peripheral does not have to report to the central before the central assumes a problem. In general, using SL makes sense when low power consumption is important (which is basically always). The previous chapter described the exchange of packets in BLE. With a Slave Latency of 2, the following communication would be observed if there is no data to exchange:

In this case, the peripheral neither needs to send nor receive data in two consecutive CIs. This creates enormous power savings potential, especially if the SL is set very high. However, in this case, the latency from the central to the peripheral must be assumed to be up to three CIs. After all, it's always possible that the peripheral has nothing to say at the moment and therefore drops two connections. It should be noted, however, that a peripheral can always send data whenever it wants. Therefore, the latency only deteriorates in one direction.

So you can remember:

If you have high requirements for the latency from central to peripheral you should set the slave latency to zero.

However, if the latency requirements from central to peripheral are not so high, using the SL makes sense. Furthermore, the SL can, of course, also be adjusted dynamically. For example, in certain situations where no (safety-critical) data transfer from central to peripheral is expected, the SL can be increased to save power.

Protocol level

In addition to the central and peripheral layers, BLE is divided into client and server. The central layer usually (but not always) assumes the role of the client, while the peripheral layer assumes the role of the server. The server defines services in the GATT (Generic Attribute Profile) layer that the client can access. A complete explanation of the GATT layer would go beyond the scope of this article. It's well described here, for example:

https://learn.adafruit.com/introduction-to-bluetooth-low-energy/gatt

To summarize: GATT determines how BLE devices communicate with each other. After all, it is the BLE communication profile. The somewhat more well-known SPP (serial port profile) does something similar, although it works completely differently. With BLE, data is exchanged via so-called services. These have characteristics which in turn have properties. Services are groups of characteristics. In simple terms, characteristics are data fields of the server. For example, the Heart Rate Service has a Heart Rate Measurement characteristic, as well as a Body Sensor Location characteristic (and others that I won't mention here). By reading the Heart Rate Measurement characteristic, you get the heart rate. By reading the Body Sensor Location characteristic, you get the location where the sensor should be worn (is the device a chest strap or a watch, for example). The heart rate can also be subscribed to, which means that the client receives a message for every change in the heart rate.

How characteristics can be accessed is controlled by the properties, i.e. properties of the characteristic:

To reduce latency, it makes sense to select the correct properties.

As a rule, write without response is best for client-to-server transfers, and notifications for server-to-client transfers.

Since these properties do not need to be confirmed, the corresponding activities can be executed much more quickly in succession. As already mentioned, BLE messages are not simply lost even without a response. Write and indications merely provide a way to reject unauthorized or incorrect access at a higher level than the link layer (e.g., a client writes an invalid value to the characteristic). This process does not provide any additional security for securing the BLE transmission.

Avoid transferring unnecessary data

As described, BLE packets are retransmitted until they arrive or the connection is terminated. The BLE standard does not specify a maximum number of retransmissions. This is useful if you want to ensure that all the information you want to send reaches the other end. On the other hand, retransmissions block new transmissions because there is no way to prioritize messages. In a disrupted connection, multiple retransmissions of a message can occur. If you send at too high a data rate in such an environment, messages will eventually build up, and the point will come where the BLE stack refuses to accept any further messages.

It is therefore recommended to only send the messages that are absolutely necessary in security-critical areas.

This avoids important messages having to wait for unimportant ones.

Many BLE stacks also offer the option to configure the maximum number of elements in the queues for notification and write processes. Typically, data cannot be stopped once it has been passed to the BLE stack. Therefore, if the queue is set too large, large amounts of data could accumulate in the stack in disrupted environments. Therefore, a low value is often recommended, so that the BLE stack starts rejecting messages early in disrupted environments. If this happens, the rejected messages can be held back at the application level and replaced with more recent or higher-priority messages.

It is also recommended to keep the messages as short as possible.

A BLE packet can contain multiple messages. This allows the BLE stack to send multiple elements of its queue at once. On the other hand, messages can also span multiple packets. If one or more packets are retransmitted, the transmission can take a very long time.

Reduce retransmissions (Bluetooth 5)

Even if you've optimized latency at the protocol level and with the help of correct Bluetooth parameters, packets will still occasionally arrive late. This is due to retransmissions, which can never be completely eliminated. What can be done about this? Overall, the options aren't very diverse. Since Bluetooth 5.0, however, you have at least these two options:

Option 1: Adaptive Frequency Hopping.

Since Bluetooth 4.0, BLE has generally used frequency hopping. Each CI operates on a different frequency band. The pattern according to which the devices hop between frequencies is pseudo-randomly determined for each new connection (calculated, among other things, from the Bluetooth addresses of the central and peripheral devices). Bluetooth 5.0 adds what is known as adaptive frequency hopping. Here, the BLE stack continuously monitors the frequencies on which it communicates. If interference occurs on one of the frequency bands, that band is temporarily deactivated. The central thus continually creates a new one. Channel Map and transmits this to the peripheral after each update. This is quite practical, but there is one crucial problem: Many BLE stack manufacturers do not support adaptive frequency hopping. Nordic Soft Devices, for example, cannot do this and at the same time does not collect any information to implement something similar themselves. Silicon Labs, on the other hand, has supported the feature since Bluetooth SDK version 2.10.

Option 2: Selecting the correct PHY.

PHY stands for the physical layer of BLE, which describes the lowest layer of the BLE architecture, which is responsible for sending and receiving BLE packets. This layer typically operates at a bit rate of 1 MHz. Since Bluetooth 5.0, the following settings have been added:

• 2 MHz
• Coded PHY 500 kHz
• Coded PHY 125 kHz

While the faster setting can primarily be used to increase the data rate, the two slower settings are primarily intended for greater range. Now you might think "faster is always better!". The problem with this, however, is that the range is significantly reduced with this setting. For this reason, although the minimum latency decreases (at least slightly), the maximum latency increases. In my opinion, this feature makes sense for firmware updates (which is what it is intended for). I wouldn't necessarily recommend it in safety-critical areas. The slower settings (Coded Phy) are actually more interesting. Here, the message is not simply sent more slowly, but (almost) every bit is actually sent multiple times (8 times at 125 kHz). This gives the receiver more options for error correction, which avoids retransmissions and significantly reduces the likelihood of very high latencies. Here, too, the problem is finding a stack manufacturer that supports all settings. While the Silicon Labs SDK supports all settings, the Nordic soft devices can receive at all settings but only transmit at 125 kHz. This is a shame, as power consumption increases significantly at 125 kHz because each bit has to be transmitted and received eight times. At the same time, the data rate also decreases significantly. Therefore, this setting is only suitable if you really want to send very small amounts of data. In comparison, 500 kHz Coded Phy offers a good trade-off.

And what if I still occasionally measure high latencies?

As already mentioned, I can measure a maximum latency over a longer period of time, but I can never guarantee it. If the distance between two devices increases or if there is interference on the 2.4 GHz band, the maximum latency increases. In safety-critical areas, it is therefore sensible to implement measures at the application level that at least detect interference. In the example with the defibrillator described above, it would make sense to send the status of the shock button at regular intervals. If the messages arrive regularly, the defibrillator knows that everything is OK and the button has not been pressed. If the messages are missing for a longer period of time, the defibrillator can at least alert the user. Basically, you should always have a backup for the connected BLE device. In the case of the defibrillator, this could be, for example, an additional shock button directly on the device.

And what are the disadvantages?

Connections optimized for latency are not necessarily optimized for data throughput. For example, if Coded PHY is used, the data rate will always suffer. The CI generally doesn't need to be set to 7.5 ms for fast data throughput. It's often better to choose long intervals so that the connection isn't constantly being established and released during a data stream. For processes that require high data rates, an additional mode may need to be implemented in which the connection is more strongly optimized for data throughput. Fortunately, all BLE parameters can be changed during an existing connection.

It's also important to note that connections optimized for latency can result in high power consumption. Low CI and SL parameters, as well as coded PHY, all negatively impact power consumption.