Coming off of the massive Bluetooth 5.2 Audio release just about 2 years ago, The Bluetooth 5.3 specification that is now available is a little different. It has a few enhancements, but it does something most other Bluetooth specifications don’t normally do – remove features.
Most developers are not familiar with Bluetooth 3.0 (called Bluetooth 3.0+HS for High Speed) and assume Bluetooth 2.1 jumped to 4.0. But Bluetooth 3.0 was released long ago with the intention of increasing the throughput. The idea was to use Bluetooth for pairing and then allow an alternative MAC to be used to provide additional throughput which was based on 802.11(aka Wi-Fi) and the throughput was going to be 24Mbps or so.
In reality Bluetooth 3.0+HS never really went anywhere, and aside from a few niche uses wasn’t used or supported by major manufacturers. Even for chipsets that supported both Bluetooth and Wi-Fi that enabled it, it was rarely used. The Bluetooth 5.2 removes this unused part of the specification – a good thing because the specification is already pretty large with several thousand pages. All the parts that were related to Bluetooth 3.0+HS were removed including:
- Alternative MAC/PHY
- AMP Manager protocol (A2MP)
- L2CAP Enhancements for AMP
- 802.11 PAL
- 802.11n Enhancements to the 802.11 PAL
The Bluetooth SIG admitted as much that the AMP was not very common:
“The frequency with which AMP has been used in qualified Bluetooth products is low and the Bluetooth Special Interest Group (SIG) has made the decision to remove this feature from Bluetooth Core Specification version 5.3”
It’s still technically possible to qualify a Bluetooth product with the AMP feature using earlier versions of the specifications, though at some point the withdrawal schedule means that won’t be possible once Bluetooth 5.2 is withdrawn. We’d say that’s unlikely to happen.
AdvDataInfo in Periodic Advertising
Periodic advertising was a feature added in Bluetooth 5.0 as part of the LE Advertising Extensions. This feature allows a BLE device to use periodic advertising to broadcast data. Instead of depending on capturing advertisements sent on 3 different channels, a device sending periodic advertisements only needs to send them once, and these advertisements are specific in time, which allows another device to receive them.
What oftentimes happens is that a receiving BLE device will get the same data multiple times, which causes increased power consumption because the filtering and processing of the data happens at higher layers.
The new AdvDataInfo feature in Bluetooth 5.3 enables adding the AdvDataInfo as part of the advertising which enables receiving devices to know if they already received the data. If they already did, they can discard it without having to pass it up to the host, which allows the system to remain in sleep for longer, reducing power consumption. Another benefit is that by not processing packets that are redundant, the device can be scanning other channels.
| Advertising Data ID (DID) 12bits | Advertising Set ID (SID) 4 bits |
AdvDataInfo Fields Format
The AdvDataInfo packet fields above are used as follows:
- Advertising Data ID (SID) is an ID set to uniquely identify the advertising sets transmitted
- Advertising Data ID (DID) is an indicator used to indicate that the data contents of the AdvData are a duplicate of previous AdvData sent in another packet
By leveraging AdvData Info and the DID, it’s now possible to avoid duplicate data from being received.
Host to Controller Encryption Key Control Enhancements (Bluetooth Classic BR/EDR)
Bluetooth Classic, like BLE, uses encryption to protect the data being exchanged between two devices. The strength of this encryption depends directly on the size of the key used.
In 2019, a new vulnerability was disclosed about Bluetooth. The KNOB attack showed that the original Bluetooth specification had a flaw – the key size used in encryption was negotiable. This meant that a very weak key of 1 byte could be used, which was trivial to break. This feature was present in Bluetooth because Bluetooth wanted to make encryption fit use cases where a large key size would be computationally difficult or too power consuming to perform. This feature gave system designers the flexibility to choose the right tradeoff between security and power consumption.
In reality, as computing power has evolved, it became trivial to brute force small keyspaces. In practice, a Man-In-The-Middle attack could make two devices negotiate a very small key size, which allowed an attacker to brute force the key and decrypt all the information exchanged. While a host could refuse to send data to the other device when the key size used is too small, this is very inefficient.
In previous specifications, the Host would check whether the key size that was selected was acceptable only when a connection had been established. With Bluetooth 5.3, the new Set Min Encryption Key size command allows the host to tell the Controller what’s the acceptable key size. The Encryption Change Event has also been updated to indicate the key size of the connections, which means the Host doesn’t have to ask the controller for it.
LE Enhanced Connection Update – Connection Subrating
Many Bluetooth devices have to switch between a low duty-cycle where they’re transmitting little data, to high-duty cycle where they need to transmit significant amount of data. One example of this are audio devices that may maintain a connection when no audio is streaming, only to suddenly starting to stream audio that requires fast data transmission.
To change from a low duty cycle to high duty cycle takes time to update the connection parameters, especially as the device has to wait for the connection event to send the request, and then wait for the connection update point itself which takes several connection events. This delay damages the user experience. To solve this problem and avoid the time required to update the connection parameters, the Connection Subrating mechanism was added to Bluetooth 5.3
In order to do this switch effectively, an existing connection is subrated – a subrating factor is selected and the Central and Peripheral skip most of the connection events. If the subrating factor is 8, then only every 8th connection event is used by the Central and Peripheral devices. This result in a low-duty cycle event which lowers power significantly, but the original connection interval is still present and can be returned to quickly to speed up the throughput (like when the Audio needs to stream).
The feature adds adds to Bluetooth LE two new PDUs: LL_SUBRATE_REQ and LL_SUBRATE_IND.
LE Channel Classification
When two Bluetooth LE (BLE) devices connect, they use a technique called Adaptive Frequency Hopping (AFH). This technique involves rapidly switching between channels in the 2.4GHz frequency band for each connection event to avoid interference that may be specific to a channel. This frequency hopping uses a channel map where a device allows or excludes channels according to some parameters in order to use only the best channels and improve performance.
Prior to version 5.3 of the core specification, only the Central device performed channel classification. This meant that issues that the Peripheral device could be seeing would not be seen by the Central and would not be accounted for. For example, when the Central and the Peripheral device are relatively far away, the channel condition that the Peripheral sees (due to interference of other nearby devices) may not be the same as seen by the Central device. In previous Bluetooth versions, this meant the Central device would choose channels that had interference because it could not detect that interference, causing dropped packets and a drop in performance.
With Bluetooth 5.3, the Peripheral device can now report its channel classifications to the Central device, ensuring that the Central device creates a channel map where the channels in both devices are accounted for. This helps reduce the chances of packet collisions and enhancing overall throughput and reliability.
This feature adds new PDUs: LL_CHANNEL_REPORTING_IND and LL_CHANNEL_STATUS_IND along with the corresponding procedure to perform this update.
Impact and Applications for Bluetooth 5.3
Bluetooth 5.3 focuses really on two things: improving the user experience and performance for many applications but especially for LE Audio, the key feature introduced in Bluetooth 5.2.
The Connection Subrating process (which is reminiscent of the Sniff subrating mode of Bluetooth Classic and inspired by it) will be useful for LE Audio (Auracast) use cases, but we can see it being leveraged by other use cases like sensors that wait for detection and suddenly generate a lot of data when an event occurs.
References
New Core Specification v5.3 Feature Enhancements
Bluetooth Core Specification 5.3
