The Bluetooth core specification contains a whole bunch of different features that enable a whole variety of use-cases. While supporting many use-cases is great, this also means that you’re faced with many different options for performing (what you would think) is a simple task.
I was originally going to title this post as “BLE Features that you should never use!”, but that wouldn’t really be fair. The fact is that every feature that’s included in the spec was added with some intention and was designed to solve some problem. So while I won’t say that should never use any specific feature, there are a handful of features in the Bluetooth spec that we’ve found that it’s best to avoid using. Our list is below, with some details behind our reasoning.
ATT Read Blob Request / GATT Read Long Characteristic Value sub-procedure
Most ATT packets have a maximum payload size that is limited by the negotiated ATT_MTU size within your connection. Oftentimes, applications require sending chunks of data that exceed these maximum values (e.g. transferring stored sensor readings, logs, or files). From looking at the spec, Blob Requests seem like the obvious solution to this problem, but if you dig a little bit deeper, you’ll realize that blob requests have a couple major limitations:
- When blob requests are used, every single packet must be individually requested, as shown in the spec (1) (see reference links) below:
This is very inefficient and requires multiple connection events in order to transfer all the data.
- Another limitation is that the maximum characteristic value is only 512 bytes, so you are still limited in size. This means that if you need to transfer a chunk of data that’s larger than 512 bytes, your application will need to fragment the data into multiple chunks before sending packets. Then on the receiving side, the application will need to re-assemble the data.
With this in mind, our philosophy is to never use read blob requests, and instead to use ATT Notifications when sending large chunks data from a GATT server to a GATT client. If the data is larger than what will fit into a single notification packet (ATT_MTU – 3 bytes), then you should fragment and re-assemble data at the application layer. By using notifications instead of ATT Read Blob Requests, multiple packets can be sent per connection event, greatly increasing your throughput. Yes, the fragmentation and re-assembly adds some complexity to your application, but there isn’t really any way to avoid it anyway if your data transfer size exceeds the 512-byte limit for characteristics.
Queued Writes / Reliable Writes (ATT Prepare Write, ATT Execute Write, GATT Write Long Characteristic Value sub-procedure)
Similar to the Blob Requests, the Queued Writes and Reliable Writes features appear to be the simple way to send large chunks of data from a GATT client to a GATT server. But unfortunately they suffer from the same limitations as Blob Requests: the transfer are inefficient and only allow a single packet containing data to be sent on a single connection event, and you are still stuck with the limit of a maximum characteristic length of 512 bytes.
For large transfers from GATT client to GATT server, we recommend using the GATT Write Without Response sub-procedure, which uses the ATT Write Command packet. Similar to notifications, the ATT Write Command PDU allows you to fit (ATT_MTU – 3 bytes) of data in a single packet and allows for multiple packets to be sent on a single connection event.
The Reliable Write feature has an extra check before the actual data is written to ensure that the correct data was received before the server processes it. If this functionality is needed, we recommend implementing some kind of hash or CRC check at the application layer rather than using the Reliable Write feature.
GATT Secondary Services / Included Services
The GATT specifications includes the concept of “primary services” and “secondary services”, in which a secondary service is not allowed exist independently but rather must be “included” by a primary service or another secondary service. In the vast majority of applications, there really isn’t much value in having a hierarchy of services. And since there isn’t much that is gained from this feature, we recommend against using it and adding to the complexity of your GATT server.
GAP Limited Discoverable Mode / LE Limited Discoverable Advertising
The idea behind limited discoverable advertising makes sense – it’s intended to be used when a peripheral device is advertising for a short period of time before stopping. This is as opposed to general discoverable advertising, in which the peripheral can advertise indefinitely.
The problem with limited discoverable advertising is that it’s restrictive. As sort of a workaround to the spec, we recommend to just always use general discoverable advertising and to enable it and disable it whenever you want. The core spec doesn’t have any restrictions for when a device can start or stop general discoverable advertising, so our philosophy is to always use it and it to set timers at the application layer if we only want to advertise for a set period of time.
L2CAP Connection Oriented Channels
The L2CAP Connection Oriented Channels (CoC) feature was added in Bluetooth 4.1 as an alternative to GATT as a means for transferring data between two connected devices. In a sense, L2CAP CoC seems like the perfect alternative to the large data transfer issues that were discussed above, in that it opens up a direct channel without requiring any ATT packets. In fact, using L2CAP CoC can actually provide a very slight increase in the maximum throughput compared to using GATT in an optimal manner, since it doesn’t require any ATT header bytes in the packets.
So why don’t we like using L2CAP CoC? The main reason is that it is not commonly used, and therefore not well supported in all Bluetooth stacks and implementations. It isn’t as simple to use as it seems, in that has a concept of “credits” to track available buffers. Since most BLE systems use GATT for communication, we recommend just sticking with it (and primarily using ATT Notifications and ATT Write Commands for transferring data).
LE Legacy Pairing
When Bluetooth Low Energy was introduced in the Bluetooth 4.0 core specification in 2010, the hardware that was available on the market was fairly limited in processing power. The devices typically had an integrated 8-bit microcontroller, a low clock speed, and very small amounts of flash and RAM. In order to enable encryption on these devices, a simple key exchange algorithm was selected even though it had known limitations. These limitations were even explicitly mentioned within the Bluetooth 4.0 core spec (2) (see reference links):
None of the pairing methods provide protection against a passive eavesdropper during the pairing process as predictable or easily established values for TK are used. If the pairing information is distributed without an eavesdropper being present then all the pairing methods provide confidentiality.
Note: A future version of this specification will include elliptic curve cryptography and Diffie-Hellman public key exchanges that will provide passive eavesdropper protection.
The Bluetooth 4.2 specification added a new feature, “LE Secure Connections”, and started referring to the older pairing method as “LE Legacy Pairing”. LE Secure Connections uses an Elliptic Curve Diffie-Hellman Key exchange procedure, which protects the link against passive eavesdroppers (3) (see references below).
In the years since Bluetooth 4.2’s adoption (2014), pretty much all devices and mobile phones now support LE Secure Connections. LE Legacy Pairing is still supported in the spec, but we recommend that you configure your device to only support LE Secure Connections and to disallow pairing requests using LE Legacy Pairing.
An Alternative Option
Instead of worrying about the different features in the core spec, there’s an easier option: the SwaraLink Bluetooth Low Energy Platform simplifies the process of writing embedded and mobile Bluetooth software altogether. With the SwaraLink platform, there’s no need to worry about services, characteristics, ATT, GATT, GAP, L2CAP, or any of these other confusing acronyms. Visit our main page at www.swaralink.com for more information or to try out our demo.
References:
(1) Bluetooth Core Specification v5.4 (page 1500)