Boosting Bluetooth low energy throughput by up to 400% and improving privacy
We are happy to announce that the latest version (v3.0.0) of our multi-role concurrent SoftDevice is now ready as production grade software.
Bluetooth 4.2 introduced a range of new features to the Bluetooth specification. Nordic has been working hard to incorporate these additions into our SoftDevices so that you as a developer can take advantage of them in the products you are developing.
This latest release has new features that dramatically improve data throughput for Bluetooth low energy, these features and the benefits they bring are described below.
Data Packet Length Extension
Data Packet Length Extension allows the Bluetooth low energy link layer to use longer packets. Previously the limit was 27 bytes, this is now extended to 251 bytes. This means less proportional overhead and acknowledgement turnaround for a given amount of data to be transmitted. An effect of having longer packets is a reduction in radio idle time for transmitting a given amount of data. These improvements can yield throughput increases of up to 400% compared to previously.
Configurable Maximum Transfer Unit (MTU)
Configurable ATT MTU size enables the ATT protocol to use longer packets than previously (23 bytes). This reduces the complexity of GATTC and GATTS procedures that handle longer characteristic values.
As an example a single ‘Write Request’ can be used instead using the ‘Queued Writes’ procedure. Once the ATT MTU size is configured, the protocol stack implements the optimal procedure. Configuring ATT MTU longer than 23 bytes also has the effect of reducing the overall header byte count, this leads to an overall increase in data bandwidth.
Example: We can transmit 138 bytes in 6 ATT packets on-air using 23 byte MTU. Using an MTU of 138 bytes means that 6 ATT packets on-air will transmit the whole 158-bytes (Assumed no increase in DLE).
This can be calculated as (158 – 138)/138 which yields a 14% improvement.
When used in combination with DLE much larger overall bandwidth gains are achieved.
Link Layer Privacy
Link Layer Privacy is a feature provides a means to avoid a device to be tracked over a period of time. When this feature is enabled the local device identity is hidden. A private address is refreshed at specified periodic intervals to ensure privacy between devices.
If a device still wishes to be recognized by peer devices, it needs to share its Identity Resolving Key (IRK). The IRK allows creation of a random private address that can only be recognized by peers in possession of that key. This allows devices to establish connections without revealing their true identity.
Link Layer Ping
LE Ping is a feature which addresses authentication during IDLE connections transmitting empty packets. IDLE connections can be exploited by a 3rd party masquerading as a legitimate peer device. This scenario presents a significant risk in, for example proximity use cases. LE Ping forces the devices to exchange at least one authenticated packet within a given timeframe to assure devices are who they say they are.
The absence of an authenticated packet within the given timeframe is indicated to the application layer and allows for corrective action to be taken if necessary.
Significant increased bandwidth for Bluetooth low energy on nRF52 series
In summary these Bluetooth 4.2 features for the S132 SoftDevice and the nRF52 series means very significant data bandwidth increases for your applications.
Over an encrypted connection, maximum throughput has increased from 150kbs to 776kbs with the use of DLE and longer ATT MTU with improved scheduling. Raw Link Layer bandwidth can be higher than 800kbs.
This development has clear benefits to Bluetooth low energy applications. It makes higher bandwidth applications that perhaps were not achievable previously, now possible.
A clear beneficiary is Over-the-Air Device Firmware Upgrades (OTA-DFU), and other data-intensive operations such as data log dumping to a peer device. Much larger amounts of data can now be transferred in a given time period with the added benefit of lower per-byte power consumption.
The S132 v3.0.0 SoftDevice for nRF52 series can be downloaded here
I just noted that SDK v12 is finally out - is there any example on using a larger MTU with S132 softdevice?
@Hung Bui: I have the same issue as Victor. Can't compile because ble_gap_whitlist_t is no longer defined in ble_gap.h. Can you please be more precise when SDK v12 will be released? 'in the matter of weeks' is not very helpful.
@victor: Before the new SDK v12 releases (which is very soon, in the matter of weeks) you can test the S132v3.0 on SDK v11. You need to use the S132v3 header files and follow the migration guide document included in the new softdevice .zip to use the new features.
Note that not all central devices (phones) now support the new feature such as DLE or long MTU.
Ah, got it. I need to port this softdevice into a project myself, so if I get it working I'll let you know what I did.
I got compile error ../components/ble/ble_advertising/ble_advertising.h:210:42: error: unknown type name 'ble_gap_whitelist_t'
Then I gave up and instead waited for new SDK as this project is not that time constrained.