Bluetooth LE throughput: Why real‑world performance falls short of specs

Many Bluetooth Low Energy (LE) applications depend on reliable, high‑throughput data transfer between connected devices. Typical use cases include over‑the‑air (OTA) firmware updates, sensor data streaming, and bulk data transport between embedded systems. Although the Bluetooth LE specification defines clear upper bounds on achievable data rate, measured throughput in real systems often falls well below these limits.

This discrepancy is not caused by a single factor. Instead, it arises from the interaction of connection‑event timing, controller scheduling behavior, protocol stack implementation, and radio‑frequency conditions.

While modern Bluetooth LE devices commonly support Data Length Extension (DLE), the 2-Mbps Physical Layer (PHY), and large Attribute Protocol (ATT) Maximum Transmission Unit (MTU) sizes, these features alone do not determine achievable throughput.

This article focuses on the practical constraints that shape Bluetooth LE Generic Attribute Profile (GATT) write throughput in deployed systems and explains why throughput behavior is frequently non‑linear and platform‑dependent.

Assumptions and test context

To isolate timing and scheduling effects from feature limitations, the analysis presented here assumes a contemporary Bluetooth LE configuration with the following capabilities:

Support for DLE on both Central and Peripheral
Use of the 2-Mbps PHY
A negotiated ATT MTU of 251 bytes
Transmit‑side buffering sufficient to queue multiple packets
Use of GATT Write Without Response operations
A receiver capable of sustaining the incoming data rate without application‑level back‑pressure

GATT Write Without Response is used to minimize protocol overhead and eliminate application‑layer acknowledgments that would otherwise consume airtime and delay buffer reuse. Although this write type omits an explicit GATT‑layer acknowledgment, delivery to the receiver’s Link Layer remains guaranteed by the Bluetooth LE protocol.

Under these assumptions, throughput might be expected to scale directly with the number of packets transmitted per connection interval. In practice, this assumption does not hold.

Theoretical throughput

With Data Length Extension enabled, a single Bluetooth LE Link Layer packet can carry up to 251 bytes of payload. After accounting for Logical Link Control and Adaptation Protocol (L2CAP) and Attribute Protocol (ATT) headers, 244 bytes remain available for application data.

Using the 2-Mbps PHY, the on‑air time for a maximum‑length data packet followed by its acknowledgment is approximately 1.4 ms. If a connection interval could be filled entirely with such packet exchanges, without additional Link Layer procedures or timing gaps, the resulting application‑layer throughput would be approximately 170 KBps.

This value represents an upper bound that is rarely approached in practice.

Connection events and packet scheduling

Bluetooth LE communication occurs within periodic connection events scheduled at intervals defined by the connection interval parameter. During each event, the Central and Peripheral exchange packets until one side terminates the event or the available time expires.

Most controllers support transmitting multiple packets within a single connection event, but the maximum number of packets allowed per event is not specified by the Bluetooth standard and is instead determined by the controller and stack implementation. As a result, packet scheduling behavior can vary significantly across platforms.

This difference is illustrated in Figure 1. In the left‑hand chart, a wireless MCU acting as the Central can pack 20 packets into a 30‑ms connection interval, using most of the available airtime before entering a short end‑of‑event dead time. In contrast, the right‑hand chart shows a smartphone operating as the Central, where the connection‑event length is capped at five packets, even though additional airtime remains available within the same interval.

Figure 1 Packet scheduling within a Bluetooth LE connection interval varies by platform. A wireless MCU Central fills most of a 30‑ms interval with data packets, while a smartphone Central limits the number of packets per connection event, leaving unused airtime. Source: Microchip

Such limits are particularly common on mobile platforms, where power management and radio coexistence requirements constrain connection‑event length. When the number of packets per event is capped, increasing the connection interval does not necessarily increase throughput, because the additional airtime cannot be used for data transmission.

Residual time and end‑of‑event dead time

Two timing effects significantly reduce usable airtime within each connection interval:

Residual time, which occurs when the remaining interval is too short to accommodate another full packet exchange.
End‑of‑event dead time, during which the controller prepares for the next scheduled event and does not permit further transmissions.

The impact of these effects is illustrated in Figure 2. The figure shows that a maximum‑length data packet followed by its acknowledgment occupies approximately 1.4 ms of on‑air time. When the remaining portion of a connection interval is shorter than this duration, the controller cannot schedule another packet exchange, even though some airtime remains available.

Figure 2 Residual airtime and end‑of‑event dead time limit packet scheduling at short connection intervals. A maximum‑size packet and its acknowledgment require approximately 1.4 ms, preventing additional transmissions when insufficient time remains. Source: Microchip

The duration of end‑of‑event dead time varies widely between controller implementations and is not explicitly defined by the Bluetooth specification. In many systems, this behavior can only be identified and quantified through direct measurement.

At short connection intervals, residual and dead time consume a relatively large fraction of each interval, limiting the number of packets that can be transmitted. At longer intervals, this overhead can be amortized across additional packets, improving average throughput if packet scheduling is not otherwise constrained.

Non‑linear throughput behavior

Because residual and end‑of‑event dead time depend on internal scheduling thresholds, Bluetooth LE throughput as a function of connection interval is often non‑linear. Small changes in the connection interval can result in unexpected increases or decreases in throughput, depending on how the interval aligns with controller‑specific timing constraints.

These effects are illustrated in Figure 3, which compares measured throughput across a range of connection intervals under different environmental and platform conditions. In the left‑hand graph, an off‑the‑shelf wireless system‑on‑chip (SoC) is evaluated as both Central and Peripheral. Measurements taken in a shielded environment (orange) show consistently higher throughput than those collected in an open office (blue), indicating the impact of ambient interference on achievable performance.

Figure 3 Measured throughput versus connection interval illustrates non‑linear behavior and environmental sensitivity. Results from both a wireless SoC platform and a Zephyr GATT throughput test show higher throughput in low‑interference conditions and increased variability at longer intervals. Source: Microchip

The right‑hand graph, derived from a Zephyr GATT throughput test, reinforces this behavior while also highlighting the non‑linear relationship between connection interval and throughput. As the interval increases, throughput does not scale monotonically; instead, it exhibits discontinuities and increased variance, particularly at longer intervals where residual and dead time are amortized over more packets.

These results emphasize that throughput cannot be predicted solely from the Bluetooth LE specification. Instead, it’s strongly influenced by platform‑specific scheduling behavior and the prevailing radio‑frequency environment.

Impact of interference

Longer connection intervals typically improve throughput in clean radio‑frequency environments by amortizing residual airtime across additional packets. However, they also increase sensitivity to interference. During long connection events, many packets may be transmitted back‑to‑back; if packet loss or repeated cyclic redundancy check errors occur early in the event, some controllers terminate the event prematurely.

When this occurs, a substantial portion of the connection interval may remain unused, resulting in a sharp reduction in throughput. Shorter connection intervals limit the amount of airtime lost when errors occur and often produce more consistent throughput in noisy environments, albeit with a lower theoretical maximum.

While parameters such as PHY speed, MTU size, DLE, and GATT characteristic length are largely fixed in modern Bluetooth LE systems, connection‑event timing and controller behavior ultimately determine achievable throughput.

The connection interval remains the primary tuning parameter, but its effect is non‑linear and highly dependent on implementation details. For systems that limit packet count per connection event, selecting an interval that closely matches the allowed packet budget is critical. When longer events are supported, throughput gains must be weighed against increased sensitivity to interference.

For design engineers, optimizing Bluetooth LE throughput requires empirical evaluation and platform‑specific characterization rather than reliance on specification‑level performance limits. At a practical level, this places increased importance on controller implementations and protocol stacks that offer fine‑grained configurability on both the Central and Peripheral sides, enabling precise control over connection parameters, event length, and buffering behavior.

Wireless MCU platforms, such as Microchip’s PIC32‑BZ6 multiprotocol wireless MCU family, are representative of designs that emphasize this level of stack configurability and visibility. By allowing engineers to tune behavior symmetrically on both ends of the link and observe the resulting timing effects, such platforms can simplify the process of analyzing throughput bottlenecks and optimizing data transfer performance under real‑world operating conditions.

The ability to measure connection‑event timing, packet scheduling, and error behavior at the controller and stack levels enables more repeatable, data‑driven throughput characterization during development.

Patrick Fitzpatrick is senior technical staff engineer for software at Microchip’s Wireless Business Unit.

Source link