The Fundamentals of BLE Throughput: What’s Possible and Why

Note: This is part one of six in our BLE throughput series. See all six articles here.

If you’re evaluating BLE for a project, throughput is probably one of the first questions you’re trying to answer. 

The answer is up to 178kB/s between two embedded devices, or around 90-100kB/s when a mobile device is on one end. Those are real numbers, and developers who hit them do so deliberately; they don’t stumble into them. BLE throughput isn’t a fixed spec. It’s the product of decisions made across multiple layers of the stack, from the physical radio settings all the way up to how your application queues outgoing data.

This article covers the three things you need to understand before those decisions make sense: how BLE connections are structured and maintained, how your application data gets packaged and transmitted through the stack, and the core principles that drive every throughput optimization covered in this series.

Connections and Data Exchange

In order to understand BLE throughput, we first need to discuss some foundational BLE knowledge: how BLE connections are maintained and how data is transferred, and how your application data is framed into each BLE layer down to each BLE packet sent over the air.

A single BLE connection consists of two devices, each with a unique role:

• Central device: Before a connection, this device scans for a peripheral device and initiates the connection. Once connected, the Central device initiates the communication in the lower layers of the Bluetooth stack. The Central is usually a mobile phone, computer, or other higher powered device.
• Peripheral device: Before a connection, this device advertises its presence, awaiting for a Central device to request a connection. Once connected, the Peripheral device responds to the Central’s communication. The Peripheral is usually a low power device such as a sensor or smart watch.

Connection Events and Packet Exchange

During a connection, the Central and Peripheral maintain a connection by exchanging packets at a negotiated interval called the Connection Interval. At every Connection Interval, the Central starts a Connection Event by sending a packet to the Peripheral. The Peripheral sends a response packet.

If there is no data to be sent, the devices each exchange an empty packet. The empty packet exchanges help each device maintain the connection and know the status of the BLE link. The empty packet for 1M PHY is 10 bytes long, meaning it takes 80us to transmit. The empty packet for 2M PHY is 11 bytes long, meaning it takes 44us to transmit.

There is always 150us between packets within a single connection event. This 150us gap is known as the inter-frame spacing (ifs).

Here is an example demonstrating timing when no application data is being exchanged. This represents basic background BLE behavior to maintain a connection.

If either or both devices have data to transmit, they transmit the data instead of the empty packet. There may be data sent in one or both directions. If data is sent only one direction, an empty packet is sent in the opposite direction.

Often, either side wants to send more data than can fit into a single packet. In such scenarios, multiple packets may be sent during a single connection event.

The following diagram shows data being sent from the Central to the Peripheral in the first Connection Event. Then in the second Connection Event, data is exchanged in both directions at first, then only in the Peripheral to Central direction.

The Peripheral must always send a packet (data or empty) in response to a packet from the Central, as the Central initiates all data exchange in the lower layers of the stack. The Peripheral cannot send a low-level packet over-the-air asynchronously – it must always send a packet in response to one sent from the Central. If the Peripheral has no data to send, the empty packet is sent as an ACK to help the Central know its sent packet was received. For the Central device, an empty packet is sent to allow the Peripheral a chance to send data in response.

How a Connection Event Ends

A single connection event ends when one of the following events occur:

• Both the Peripheral and Central send a packet with the header’s “More Data” bit set to 0, indicating there is no more data to be exchanged. Empty packets typically have the “More Data” bit set to 0.
• A packet fails to be received by either the Peripheral or Central.
• The allotted time for the Connection Event runs out. Even if the Central has more data queued up to send, it will defer them until the next Connection Event. The Connection Event duration cannot exceed the Connection Interval. Note that some googling may suggest there is a maximum number of packet exchanges supported by certain phones, but due to Data Length Extensions and other factors causing variable packet lengths, the Connection Event is usually time-limited rather than packet-limited.

Often, especially with mobile phones, the Connection Event duration is further limited to a portion of the Connection Interval, for example, 50%. This is because the mobile phone may need to perform other actions in the 2.4GHz realm such as WiFi, manage other BLE connections, or perform classic Bluetooth operations. None of these actions can be performed concurrently, as they can create wireless interference with each other on the same or neighboring antennas.

Once the connection event ends, the Central and Peripheral wait for the next Connection Event based on the negotiated connection interval.

Packet Framing

When sending data over BLE, your application calls into a Bluetooth stack to send the data on a GATT characteristic. When this occurs, the Bluetooth stack does the following for standard transfer of data within a connection:

• The data is placed into an ATT PDU. The ATT PDU for the most common operations (e.g. Write Command, Write Request, Notification, Indication) has a 3 byte header. The total length of the application payload cannot exceed the ATT MTU or 512 bytes, whichever is lower. The ATT MTU is negotiated between the Central and Peripheral.
• The ATT PDU is placed into an L2CAP PDU. The L2CAP PDU has a 4 byte header. The L2CAP maximum length per the Bluetooth specification is 65355, so for most considerations, the L2CAP maximum length can be ignored because the ATT PDU length is more limiting. Additionally, Bluetooth stacks likely apply a much lower limit than 65355.
• The L2CAP PDU is placed into one or more Link Layer PDUs. The Link Layer PDU length cannot exceed the maximum negotiated length, which varies between 27 and 255 bytes. If the L2CAP PDU exceeds the maximum payload length supported by a single LL PDU, then the L2CAP PDU is fragmented into multiple LL PDUs. When the other device receives all of the LL PDUs, the L2CAP PDU is recombined.
• Each LL PDU is transmitted over-the-air. A single ATT message may be sent through a set of LL PDUs within one Connection Event or across  multiple Connection Events. Likewise, separate ATT PDUs may be sent in a single Connection Event.

The receiver unpacks each of these layers in the opposite order until the ATT PDU provides the original application message.

This flow applies to data sent in either direction. While the ATT operations are different, the underlying packet framing and transfer mechanisms are the same.

Overhead Per Packet

Every Link Layer packet has at least 10 bytes of Link Layer data, which is effectively overhead relative to application data. This overhead includes a 1-2 preamble, 4 byte access address, 2 byte PDU header, and 3 byte CRC.

Using BLE encryption will affect the maximum BLE packet length. When encrypting a message, the Message Integrity Check (MIC) is a 4-byte code included in the Link Layer.

In total, each Link Layer packet has overhead as follows (Coded PHY and Constant Tone Extension are excluded due to not aligning with high throughput use cases):

The 4 bytes of L2CAP header and 3 bytes of ATT header contribute to overhead as well. These are in addition to the values in the table.

Lastly, because a single ATT message may be fragmented into multiple LL PDUs, a single ATT message may be sent across more than one connection events.

Every byte of that overhead is a byte not carrying application data. At scale, across hundreds of packets per second, it adds up and it’s why minimizing overhead is one of the core levers for throughput.

Principles for High Throughput

Now that we’ve covered the basic mechanics of BLE, we have the foundation to understand the theory behind maximizing throughput. At a high level, a few basic principles for maximizing throughput include:

• Transmitting at the highest physical bit rate
• Maximizing “Air Time”
• Minimizing protocol overhead
• Designing for fault tolerance for your use cases

Transmitting at the highest physical bit rate: Higher physical bit rates sent over the air translate to a higher bit rate of application data. BLE has a few PHY modes that impact bit rate but also affect wireless performance.

Maximizing “Air Time”: Utilize the RF airwaves as much as possible to send data. BLE requires inherent radio idle time and two-way packet exchange, but understanding how to keep the radio transmitting in the direction of high throughput as much as possible is critical for high throughput.

Minimizing Protocol Overhead: The BLE stack needs to apply various headers and overhead to each packet sent over the air. Minimizing the percentage of these overhead bytes in relation to the application data results in higher throughput. Additionally, the BLE protocol includes packets for managing a connection and communication.

Designing for fault tolerance for your use cases: Any wireless protocol is inherently prone to faults like dropped packets due to interference. Understanding how the BLE stack handles these scenarios and applying them to your application’s use cases can ensure throughput is maximized for your unique application.

By going through the BLE stack layer-by-layer, we can comprehensively understand how to put these principles into practice.

Where to Go From Here

You now have the foundation to understand why the decisions ahead matter. To close the loop on the opening question: 178kB/s device-to-device and around 90-100kB/s with a mobile device on one end are achievable numbers, but only with deliberate configuration decisions across every layer of the stack. A good place to start is at the bottom of the BLE stack: PHY mode selection. That’s what the next article in this series covers.

Up next: PHY Selection for BLE Throughput →