KBA_BT_0404: Throughput with Bluetooth Smart technology
08/218/2015 | 07:42 AM
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 125byte useful payload / connection interval, the radio can (assuming no lost packets and no re-transmissions) achieve a theoretical data rate of:
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
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:
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 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)
<=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. 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:
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:
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 1Mbps.
Bluetooth 5 (introduced in Bluetooth SDK v2.3) specifies more PHY bitrates:
2Mbps
1Mbps.
500kbps (1Mbps with 1:2 convolution coding)
125kbps (1Mbps 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 = 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!
1Mbps
2Mbps
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:
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:
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
too much packets may be queued while waiting for next connection interval, and you can run out of memory,
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: 2Mbps
In this case 8 packets fit into one connection interval (8*1400us = 11200us), and the theoretical throughput is:
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,
Ivan
0
Hi,
One question:
BluegigaAdmin wrote:
At the time of writing this article, the Bluegiga Bluetooth Smart software v1.1 is able to buffer up to 8 packets to be transmitted within a single connection interval, so when using a non-acknowledged data transmission you can achieve a theoretical data rate of:
----
Do you know the limitation in buffer for the BLE121LR module in one single connetion interval?
Thanks
Sergio
0
Hi,
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.
Many thanks!
Prabha
0
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?
0
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.
KBA_BT_0404: Throughput with Bluetooth Smart technology
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:
1. Throughput calculation for acknowledged data transfer
In case of acknowledged data transfer the throughput depends on the following parameters:
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 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
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
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:
1.4 Maximum achievable throughput with ACK
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
2. Throughput calculation for unacknowledged data transfer
In case of unacknowledged data transfer the throughput depends on the following parameters:
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 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:
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:
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 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:
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.
2.3. PHY (physical layer) bitrate
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!
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:
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.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
2.5. Maximum achievable throughput without ACK
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
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.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.
Reference: https://blog.bluetooth.com/exploring-bluetooth-5-how-fast-can-it-be
Hi!
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,
Ivan
Hi,
One question:
BluegigaAdmin wrote:
Hi,
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.
Many thanks!
Prabha
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?
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.