This article discusses the maximum achievable bitrates on Blue Gecko devices with different Bluetooth SDK versions. However, the principles can be applied for legacy devices (BLExxx) too, taking into account their parameters.
The application-level data throughput with Bluetooth Low Energy is affected by many factors. We can differentiate two kind of operation for which the throughput calculation is quite different:
1) Acknowledged data transfer. In this case the reception of all data packets is acknowledged by the receiver. The receiver sends a response for every read/write request in the next connection interval. The connection in this case is reliable but the throughput is low.
2) Unacknowledged data transfer. In this case packets can be sent right after each other without waiting for the other side to acknowledge. This ensures much higher throughput, but a less reliable connection.
Acknowledged and unacknowledged operation can be mixed on the same connection by sending packets of different types. The following packet types result in acknowledged operation:
The following packet types result in unacknowledged operation:
In case of acknowledged data transfer the throughput depends on the following parameters:
The connection interval defines how often one can send data, and it varies between 7.5 ms up to 4000 ms. Once the sender side sends the data (or request), it has to wait for the receiver side to send an acknowledgement. Therefore one (GATT) operation takes 2 connection intervals.
The lower the connection interval, the higher the potential data rate is. E.g. using the smallest connection interval of 7.5 ms e.g. with 125byte useful payload / connection interval, the radio can (assuming no lost packets and no re-transmissions) achieve a theoretical data rate of:
1000 ms / (2 * 7.5 ms) * 125 bytes = 8,333 bytes/sec = 66,666 bps
On the other hand, when using the largest connection interval of 4000 ms e.g. with 22byte useful payload, the data rate will be reduced to:
1000 ms / (2 * 4000) ms * 22 bytes = 2.75 bytes/sec = 22 bps
MTU (maximum transfer unit) size means how many bytes can be sent within one GATT operation, i.e. how many bytes can be sent within 2 connection intervals. The MTU size can be set for each connection. However, it has an upper limit, which varies with the Bluetooth stack versions. The maximum MTU size for each Bluetooth stack version is summarized in the following table
|Bluetooth stack version||Maximum MTU size|
|For legacy devices (BLExxx)|
|For Blue Gecko devices|
|2.3.x or later||250|
Note: the MTU size depends on both sides. If the remote device support smaller MTU size, then the smaller MTU size will be used.Obviously, the higher the MTU size is, the higher the throughput is. Twice the MTU size doubles the throughput.
It is important to know that the MTU size includes the GATT header which has variable length. This means that the useful payload is a bit smaller than the MTU. The size of the GATT header depends on the operation type, hence the maximum useful payload is different for different operations. This is summarized in the following table:
|ATT operation||Max useful data / ATT operation|
|Read||MTU - 1 bytes|
|Write||MTU - 3 bytes|
|Indication||MTU - 3 bytes|
|Prepare write||MTU - 3 bytes|
|Signed write||MTU - 15 bytes|
In case of acknowledged operation the maximum throughput can be achieved with the following parameters:
This results in a maximum throughput of
1000 ms / (2 * 7.5 ms) * (250 - 1) bytes = 16,600 bytes/sec = 132,800bps
In case of unacknowledged data transfer the throughput depends on the following parameters:
Data over Bluetooth is sent in packets. Multiple packets can be sent within one connection interval right after each other (with 150us inter-frame spacing). Packets have variable length, but their length has an upper limit. The maximum PDU (protocol data unit) size of a packet depends on the Bluetooth stack version as summarized in the following table:
|Bluetooth stack version||Bluetooth standard||Maximum PDU size|
|For legacy devices (BLExxx)|
|For Blue Gecko devices|
|2.6.x or later||5.0||251 byte|
Twice the packet size does not mean double throughput, since larger packets take more time to be sent and hence less packets can be sent during the same time interval. However, the larger the packet size the smaller the overhead. This increases the application level data throughput.
E.g. in case of a 27 byte PDU it takes
328us + 150us + 80us + 150us = 708us
to send out a packet. 328us is the effective transmitting time, 150us is IFS (interframe space), 80us is receiving, 150us is IFS again. This means a theoretical data rate of:
27 byte / 708us = 38,135 bytes/sec = 305,080 bps
In case of a 251 byte PDU it takes
2120us + 150us + 80us + 150us = 2500us
to send out a packet. This means a theoretical data rate of:
251 byte / 2500us = 100,400 bytes/sec = 803,200 bps
Note: the packet size depends on both sides. If the remote device support smaller packet size, then the smaller packet size will be used.
For more details on packet timing see the following article:
It is important to know that the PDU size includes the L2CAP header which is 4 byte long and the GATT header which has variable length. This means that the useful payload of a packet is a bit smaller than the PDU size. The size of the GATT header depends on the operation type, hence the maximum useful payload is different for different operations. This is summarized in the following table:
|ATT operation||MAx useful data payload of a packet|
|Write without response||PDU - 4 - 3 bytes|
|Notification||PDU - 4 - 3 bytes|
This means that sending out notifications with 251 byte PDU, the theoretical effective data rate is:
(251 – 4 – 3) byte / 2500us = 97,600 bytes/sec = 780,800 bps
If the MTU is larger than the PDU, then multiple packets can be sent within one GATT operation. In this case only the first packets contains the L2CAP header and the GATT header, and the following packets contain only data within the PDU.
Bluetooth 4.2 specifies the PHY bitrate to be exactly 1Mbps.
Bluetooth 5 (introduced in Bluetooth SDK v2.3) specifies more PHY bitrates:
These bitrates only define the symbol time and not the effective throughput. However, the higher the PHY bitrate, the higher the throughput is. Double bitrate means nearly double throughput. It is not exactly double because of the constant IFS (IFS = 150us for both 1Mbps and 2MBps)
The following table summarizes how long it takes to send out a packet with different PDU sizes and PHY bitrates. The times include transmitting + IFS + receiving + IFS!
|27 byte||708 us||---|
|38 byte||796 us||548 us|
|128 byte||1516 us||908 us|
|160 byte||1772 us||1036 us|
|251 byte||2500 us||1400 us|
E.g. if you use 2Mbps PHY with 251 byte PDU, the theoretical throughput is:
(251 – 4 – 3) byte / (1060 + 150 + 40 + 150) us = 174,285 bytes/sec = 1,394,280 bps
For more details see:
If acknowledgement is not required, any number of packets can be sent within one connection interval. Hence the connection should not directly influence the throughput. Data packets, however, must be aligned so that the first packet starts at the start of the connection interval. E.g. if you have 7.5ms connection interval, 251byte PDU, 2Mbps PHY, then you can send 4 packets in one connection interval. The 5th packet does not fit, and have to wait for the next connection interval to start.
This means that the effective throughput with these parameters is:
4 * (251 – 4 – 3) byte / 7500us = 130,133 bytes/sec = 1,041,066 bps
To avoid the overhead introduced by skipped packages, you can adjust the connection interval so, that the remaining time at the end of the connection interval is minimal. Longer connection intervals usually mean smaller overhead due to less frequent re-adjustment.
However, be careful, if the connection interval is too long
In case of unacknowledged operation the maximum throughput can be achieved with the following parameters:
In this case 8 packets fit into one connection interval (8*1400us = 11200us), and the theoretical throughput is:
8 * (251 – 4 – 3) byte / 12,500us = 156,160 bytes/sec = 1,249,280 bps
The connection parameters and the MTU size depend on both devices participating in the connection. When connecting to a smartphone, the devices start to negotiate about the connection interval and the MTU size. Depending on the smartphone and OS version the minimum connection interval can be much greater than 7.5ms and the maximum MTU size can be less than the MTU size supported by the Blue Gecko. This has a critical effect on throughput. The negotiated parameters are signaled by the stack events gecko_evt_le_connection_parameters and gecko_evt_gatt_mtu_exchanged, so you can check what parameters are supported by your phone.
What about the throughput from the side of central (or master) device?
If several slaves are connected to one master via multiple connections, each providing 8-10 kbps (via acknowleged transmission) of traffic, would master safely recieve all that data?
For example, in my application I use BLE112 module to connect it to a built-in my laptop Bluetooth device, which I control through Windows desktop application. My Laptop's Bluetooth device is a master (it initializes connection to BLE112).
Is my Laptop will be able to handle several BLE112 modules, each providing 8-10 kbps of acknowledged traffic? (it would act as a master with each device)
Or maybe it depends on device which is built-in my Laptop?
Thanks for replies,
I am trying to transfer software image.
The setup is: [Embedded device(slave) and BLE112 Dongle + PC (Master)]. Using python script.
As per the setup, obtained transfer data rate is 170 bytes/sec.
I am using bglib API ble_cmd_gap_connect_direct(self, address, addr_type, conn_interval_min, conn_interval_max, timeout, latency) and even after changing the conn_interval_min parameter to 7.5ms, it takes the minimum connection interval of 80ms which results in low data rate.
I want to reduce the connection interval so that I can increase the data rate upto 2KB/sec.
Can you please clarify how to achieve the minimum connection interval of 7.5ms using BLE112 dongle on python side.
It would be of great help.
I think there is a mistake in 2.5 Maximum achievable throughput without ACK.
You said: "If the MTU is larger than the PDU, then multiple packets can be sent within one GATT operation. In this case only the first packets contains the L2CAP header and the GATT header, and the following packets contain only data within the PDU"
Therefore, the calculation shouldn't subtract L2CAP and GATT headers in the seven packets after the first one. I assume all the PDU bytes are used for actual user data in those seven packets.
Is this true?
Is this correct for section 2.4. Connection interval?
E.g. if you have 7.5ms connection interval, 251byte PDU, 2Mbps PHY, then you can send 4 packets in one connection interval. The 5th packet does not fit, and have to wait for the next connection interval to start.
I'm calculating that 5 packets will fit in one 7.5ms connection interval:
251 byte PDU @ 2Mbps PHY: (1060 + 150 + 40 + 150) us = 1400 us
7.5 ms connection interval / 1400 us = 5.36.
So it appears that you can fit 5 packets per connection interval, unless there's some additional "T align" overhead that I'm not accounting for, but I couldn't find any additional information on this.