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:

• Read (read request)
• Write (write request)
• Indication
• Prepare write
• Signed write

The following packet types result in unacknowledged operation:

• Write without response (write command)
• Notification

 

1. Throughput calculation for acknowledged data transfer

In case of acknowledged data transfer the throughput depends on the following parameters:

• Connection interval
• MTU size
• Attribute protocol operation

 

1.1 Connection interval

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 125-byte 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 22-byte useful payload, the data rate will be reduced to:

1000 ms / (2 * 4000) ms * 22 bytes = 2.75 bytes/sec = 22 bps

 

1.2 MTU size

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)
<= 1.5.0	23
For Blue Gecko devices
1.0.x	23
2.0.x	58
2.1.x	126
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.

 

1.3 Attribute protocol (ATT) operation

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

 

1.4 Maximum achievable throughput with ACK

In case of acknowledged operation the maximum throughput can be achieved with the following parameters:

• Connection interval: 7.5 ms
• MTU size: 250 bytes
• Attribute protocol operation used: Read

This results in a maximum throughput of

    1000 ms / (2 * 7.5 ms) * (250 - 1) bytes = 16,600 bytes/sec = 132,800bps

 

2. Throughput calculation for unacknowledged data transfer

In case of unacknowledged data transfer the throughput depends on the following parameters:

• Packet size
• Attribute protocol operation
• PHY (physical layer) bitrate
• Connection interval

 

2.1. Packet size

Data over Bluetooth is sent in packets. Multiple packets can be sent within one connection interval right after each other (with 150 us 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)
<=1.5.0	4.0	27 byte
For Blue Gecko devices
1.0.x	4.0	27 byte
2.0.x	4.2	38 byte
2.1.x	4.2	38 byte
2.3.x	5.0	128 byte
2.4.x	5.0	160 byte
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. 328 us is the effective transmitting time, 150 us is IFS (interframe space), 80 us is receiving, 150 us is IFS again. This means a theoretical data rate of:

27 byte / 708 us = 38,135 bytes/sec = 305,080 bps

In case of a 251-byte PDU it takes

2120 us + 150 us + 80 us + 150 us = 2500 us

to send out a packet. This means a theoretical data rate of:

251 byte / 2500 us = 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:
https://blog.bluetooth.com/exploring-bluetooth-5-how-fast-can-it-be

 

 2.2. Attribute protocol operation

It is important to know that the PDU size includes the L2CAP header, which is 4 bytes 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 / 2500 us = 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.

 

 2.3. PHY (physical layer) bitrate

Bluetooth 4.2 specifies the PHY bitrate to be exactly 1 Mbps.

Bluetooth 5 (introduced in Bluetooth SDK v2.3) specifies more PHY bitrates:

• 2 Mbps
• 1 Mbps.
• 500 kbps (1 Mbps with 1:2 convolution coding)
• 125 kbps (1 Mbps with 1:8 convolution coding)

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 = 150 us for both 1 Mbps and 2 Mbps)

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!

	1 Mbps	2 Mbps
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 2 Mbps 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:
https://blog.bluetooth.com/exploring-bluetooth-5-how-fast-can-it-be

 

2.4. Connection interval

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.5 ms connection interval, 251-byte PDU, 2 Mbps 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 / 7500 us = 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

1. too much packets may be queued while waiting for next connection interval, and you can run out of memory,
2. you may have to wait much more for resynchronize if connection breaks due to consecutive CRC errors. Long connection interval is hence not recommended in noisy environments, where CRC errors are expected.

 

2.5. Maximum achievable throughput without ACK

In case of unacknowledged operation the maximum throughput can be achieved with the following parameters:

• Connection interval: 12.5 ms
• PDU size: 251 bytes
• Attribute protocol operation used: Write without response / Notification
• PHY bitrate: 2 Mbps

In this case 8 packets fit into one connection interval (8*1400 us = 11200 us), and the theoretical throughput is:

8 * (251 – 4 – 3) byte / 12,500 us = 156,160 bytes/sec = 1,249,280 bps

 

3. Considerations for smartphones

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.5 ms 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.

 

Reference: https://blog.bluetooth.com/exploring-bluetooth-5-how-fast-can-it-be