The Instaburst feature is a drop-in replacement for the standard BLE Advertiser bearer for the Bluetooth mesh. When enabled, all communication in the core Bluetooth mesh will happen through Instaburst instead of regular advertisers, yielding higher throughput, but breaking compatibility with other Bluetooth mesh implementations.
In optimal conditions, Instaburst is able to transmit 498 bytes of raw advertising data every advertising interval, providing a 160-kbps bearer to the upper layers for 20-ms advertisement intervals. The Bluetooth mesh packets have significant overhead however, and under the same conditions the maximum theoretical access layer payload throughput is around 60 kbps.
Table of contents
Instaburst uses a subset of the Bluetooth 5.0 Extended advertising events feature to increase the throughput. It runs a dynamic buffer allocation algorithm that makes a per-packet decision on whether to transmit it as a regular advertisement packet or as an extended advertising event. This maximizes throughput while minimizing the radio time spent by each Bluetooth mesh device.
All Instaburst usage of advertising extensions is done with a locked configuration that always runs:
Every advertisement event contains a set of packets:
To remain scalable for larger Bluetooth mesh networks, the chain length is limited to this initial auxiliary packet and a single chain packet.
For more information about the extended advertisement protocol, see the Bluetooth Core 5.0 specification.
When Instaburst is enabled in the build, the Bluetooth mesh will:
To start using Instaburst, enable the EXPERIMENTAL_INSTABURST_ENABLED option in the CMake configuration. This also enables Instaburst for the Segger Embedded Studio project files, which must be regenerated (see Building the stack and examples for details).
As the extended advertising packets have dynamically-sized headers and are allocated on a per-advertising event basis, the buffer management in the Instaburst TX module is different from the pattern of the advertiser module.
The Instaburst packets are allocated on a per-advertising event basis, with:
To match the advertiser API, each user buffer allocated in the Instaburst TX API must be tied to a TX token (which will be passed back to the user once the packet has been sent). TX tokens are used for internal book keeping, and shouldn't go on air. As there are multiple user buffers in a single packet, the TX tokens must be allocated separately. To avoid constraining the amount of separate user buffers that go into a single extended advertisement event, the tokens are stored at the end of the advertising event buffer, in reverse order.
The buffer is considered full when the list of tokens has grown to meet the list of packets. To reduce the amount of memory that the token list takes off the packet list, some extra padding space is allocated between the maximum length of the packet list and the end of the buffer, where the token list starts.
The sizes of dynamic headers of the extended advertising packets are determined by the packet's role in the advertising event. At the time of transmission, the module decides which fields in the common extended advertising header are to be included.
To avoid moving the payload according to the size of the header, the Instaburst packets are allocated with the worst-case size header buffer, before the payload. Then, before transmitting the packet, the module calculates the size of the header and builds it in such a way that it ends exactly where the payload buffer begins, leaving out some padding ahead of it in the header buffer.
Instaburst RX buffers work the same way as the Advertiser RX buffers. They store each Extended advertising packet in the buffer as a separate entity, bundled with its metadata.