Bluetooth Low Energy Serial: A Valid Design Strategy?

At some point in developing a connected product for BLE, you may have wondered, “Where is the serial profile?” Maybe you assumed that you missed it while scrolling through the long lists of profiles on the Bluetooth SIG’s website. Or, maybe you never looked, preferring the faster method of implementing the serial API provided by your chipset. Either way, no official Bluetooth profiles support a serial Rx/Tx pair. 

So, is Serial over Bluetooth Low Energy just a dirty hack used by those unwilling to learn to do things the Bluetooth way? Or, does the Serial over BLE strategy bring legitimate benefits? 

Here are a few things to keep in mind the next time you design the communication strategy for your connected product.

Bluetooth Low Energy (BLE) was designed as a low power alternative to Bluetooth (now Bluetooth Classic). BLE allows devices to communicate for years on a coin cell battery. BLE achieves this by focusing on sending small chunks of data as efficiently as possible. To achieve this efficiency, a client server architecture, named the Attribute Protocol (ATT) was adapted. 

The ATT is made up of Services, Characteristics, and Descriptors. In this article, each of these objects will be referred to as a profile. Descriptors belong to Characteristics and represent properties of that characteristic. Characteristics possess a state that clients interact with by reading, writing, or subscribing to changes of. Services are groups of characteristics.

BLE doesn’t sound anything like a serial protocol, does it? That’s because all of the overhead associated with serial packets is abstracted, leaving a simple read, write, and notify interface. Nevertheless, chipmakers have embraced Serial over BLE, and each have created custom profiles and APIs for implementing Serial over BLE on their chipsets.

Microchip Technology’s Transparent UART Service, Nordic Semiconductor’s Nordic UART Service, and Texas Instruments’ Serial Port Service are just a few of the custom profiles created for Serial over BLE. They do this for a good reason, as there are many benefits to choosing Serial over BLE for your Bluetooth Low Energy product.

Note: Serial over BLE is referring to an ATT design made up of a single service containing one RX characteristic with only the notify/indicate permission, and one TX characteristic that only allows writing.

Reasons to Use Serial Over Bluetooth Low Energy

The driving reason for using Serial over BLE is that it is easier to implement. For embedded engineers, designing and implementing serial protocols is as simple as breathing. By sticking with what’s familiar, development moves faster, and the end product is more reliable. 

Besides familiarity, using Serial over BLE means that the application data sent over BLE is in a format that’s interoperable with other wired and wireless transport protocols (UART, SPI, Wi-Fi, etc.). For this reason, Serial over BLE also provides huge advantages when the BLE stack is on a different processor than the main application.

Running the BLE stack on a separate processor from the main application is a common embedded architecture strategy. These BLE coprocessors range in complexity from full SoCs to dedicated BLE stacks with just enough to get the job done. 

Regardless of the hardware’s capabilities, if the processor does not run the main application, then the simplicity of configuring and interacting with the BLE chip as if it were just another UART line is very appealing. Changing the packet protocol, sending new kinds of data, and implementing packet infrastructure (such as length or packet identifier fields) can be done without changing anything on the BLE coprocessor because the coprocessor doesn’t care what it’s sending, it simply forwards everything along.

Serial over BLE can generally set up connections faster. As you can see in Figure 1, the connection setup time tends to scale linearly with the number of services, characteristics, and descriptors discovered. 

“Discovering” refers to the process of mapping out the handles of all services, characteristics, and descriptors so that the app is aware of what they are, and can refer to them later. For each additional service, characteristic, or descriptor that needs to be discovered on connection start, you can expect to add between one and three connection intervals worth of time before the connection can be used to transfer application data. 

Connection intervals are generally 30ms for iOS but can go as low as 7.5ms on Android. A Serial over BLE architecture can be made to only use one service and two characteristics, yet transport a large variety of data.

Drawbacks of Serial Over Bluetooth Low Energy

Nearly every form of digital communication is based on a serial protocol with varying levels of encapsulation, even Bluetooth Classic. 

So, why shouldn’t you use Bluetooth Low Energy as a simple wireless UART link?

The most considerable downside of Serial over BLE is higher application latency. Increases in application latency can lead to poor user experience, and waste time that the device could spend conserving energy in a low power state.

As you can see in Figure 2, when a request is received, it must be passed to the peripheral’s application layer to be executed. After the request is executed, the response must be encapsulated in the proper packet. The response packet is then given to the peripheral’s BLE stack, which sends an indication to the central. 

Even if the peripheral application is returning a piece of data straight from memory, it will take at least two connection intervals for the central to receive the data requested. Considering that in most cases every request that the application makes to the BLE layer needs to be queued, you are generally looking at several more connection intervals occurring in the time that it takes for the central to receive a response to its request.

For a standard BLE read request, as seen in Figure 3, the characteristic’s state is kept up to date by the peripheral application. When read, the characteristic already contains the data being requested, and the response occurs immediately. The request and response is kept within a single connection interval.

Application latency is also higher in Serial over BLE models because neither device in the connection can filter for only the types of data that they’re interested in. Therefore, all packets must be sent over BLE and passed to the application layer before the unimportant ones can be discarded. 

Another way that time and energy are wasted in the Serial over BLE strategy is the overhead added by the application layer packets. Packet identifiers, length fields, and checksums are all examples of fields added to application layer packets in a Serial over BLE strategy. The same fields are also added to the encapsulating BLE packet. Each of these duplicate fields add more bits for the BLE radio to transmit, and provide minimal value as the BLE protocol has its own mechanisms in place to handle any issues.

If your BLE product is intended to talk to devices running iOS and Android, there are several other considerations to keep in mind. First, complex packet protocols will need to be more thoroughly documented for the developer (who’s most likely on a different team) to implement. Serial over BLE packets also require the mobile application to have a central packet handling infrastructure that checks all of the packet protocol values to know how to parse out the useful info and where to send it. Finally, mobile programming languages make it harder to manipulate objects smaller than a byte, so Serial over BLE packets should only be made up of byte-sized (Reeses?) pieces. 

The final drawback of Serial over BLE to mention is that using custom packet protocols severely limits interoperability with other BLE software. As the number of devices with BLE radios grows, it’s not hard to imagine the possibilities for devices that communicate with both their partner application, and other BLE-based systems; the true unifying power of the Bluetooth SIG profiles.

What Should You Use in Your Connected Product

Now that you know the advantages and drawbacks of Serial over BLE communication strategies, you’re probably wondering, “How do I decide what’s right for my product?” 

The answer is very much up to the designer, as either approach will get you a functional product that performs the tasks it was designed for. However, the design approach affects both the ease of product development and how efficiently your product performs its purpose. 

The first thing to keep in mind when comparing communication strategies is your product’s physical constraints. If throughput is your priority, then a serial strategy will let you get the most data across in the least amount of time, especially if the bulk of the data flows in one direction. I’d also recommend checking out our blog post series “Maximizing BLE Throughput” to learn how to get the most performance out of your BLE radio. If your Bluetooth module is short on processing power, then the simplest way to interface with that module is through a serial strategy.

The above constraints all seem to point toward the Serial over BLE strategy. If you are building a product that does not push the hardware to its physical constraints, than you should focus on the user experience constraint: Latency.

Good user experience first comes from building devices that work right every time and are intuitive to use. That is, of course, if latency doesn’t tank an otherwise good UX. In this case, we’re looking at optimizing for connection latency vs. application latency. 

Connection Latency is the time needed when connecting to get to the point where application data can be transferred. Application latency, on the other hand, is the time it takes between the application making a request of the connected device and the application getting a response back. 

Connection latency is improved by using faster advertising rates, and by using fewer services and characteristics, such as in a Serial over BLE strategy. However, implementing Serial over BLE is done at the cost of application latency, especially when information is streamed continuously by default during connections. 

Using the client-server design avoids this application delay, and can assist in providing lightning-fast responses. For devices that use long-running connections, the tradeoff between connection setup time and application latency should be a no brainer. Start adding characteristics to your heart’s content.

Hybrid Models: The Best of Both Worlds

The Serial over BLE strategy and the Client-Server approach are two ends of a spectrum. For many products, the best design lies somewhere in the middle. 

At Punch Through, clients usually come to us after having implemented the Serial over BLE strategy. When we do get the opportunity to write a product’s communication protocol from scratch, we generally end up designing a hybrid strategy. 

The following are some of our rules of thumb for designing a hybrid BLE architecture:

• Start with a Serial over BLE strategy and extract functionality as needed.
• Any value that will need to be accessed quickly by the central should have a readable characteristic that the peripheral always keeps up to date.
• Bulk background transfers, such as logs or firmware updates, should have their own characteristics, so they don’t clog up communication related to the user experience.
• Status information that changes quickly should be grouped so that the information can be considered a snapshot of a single point in time. This is extremely useful when working with systems where data from multiple kinds of sensors is needed to describe the device’s status.
• Information that is not of use to the current client should be transferred through a different characteristic or should have the ability for the client to turn the information on or off based on its interests. This way, the client can control what information it receives.
• Information that can be of value to other systems should be exposed through standard Bluetooth Profiles. (Information such as battery level, temperature, etc.).

This concludes our first piece on BLE protocol design strategies. I hope that what you’ve read helps you to build better connected products.