Encryption Key Size Control Enhancements
New and enhanced Host Controller Interface (HCI) commands provide more efficient methods for hosts to ensure a minimum acceptable key length is used to encrypt a connection between Bluetooth Classic (BR/EDR) devices. These HCI enhancements can improve signaling efficiency in many Bluetooth Classic products, as the use of encryption is either mandatory or highly encouraged in all Bluetooth BR/EDR connections.
Bluetooth® wireless devices typically use encryption to ensure unauthorized third parties cannot access data being transmitted between two connected devices. One key factor that determines the strength of the protection provided is the size, or length, of the key being used to encrypt the data. In Bluetooth Classic (BR/EDR), the key size used to encrypt data is negotiated by the two controllers during connection establishment. It is up to the hosts to subsequently query their controllers to ensure a key of an acceptable minimum length has been selected, and if not, the hosts can choose to not send data over the connection. While this method can ensure data is not transmitted over connections that hosts do not see as appropriately protected, it is not the most efficient.
To improve the situation, Bluetooth Core Specification version 5.3 introduces a new optional Host Controller Interface (HCI) command (Set Min Encryption Key Size) that enables a host to specify the minimum key size a controller may accept when establishing a connection to another device. In addition, the current HCI command controllers use to inform hosts when the encryption settings on an existing connection have been changed (Encryption Change Event) has been enhanced to include the key size of the changed connection, improving signaling efficiency by eliminating the need for a host to subsequently query the controller to discover that information.
A new connection subrating feature enables rapid switching between low and high duty cycles on established LE ACL connections, improving the UX of certain use cases.
A low duty cycle connection uses little power, while a high duty cycle connection will use more power but provide higher bandwidth. Some Bluetooth® device types are required to maintain a low duty cycle while performing their primary function to conserve power while also supporting additional use cases that require a higher duty cycle as needed. For example, a Bluetooth hearing aid spends most of its time in a low duty cycle while amplifying sound but must quickly transition to support a higher duty cycle if the user receives a phone call or plays music on her smartphone.
Changes to the duty cycle can take time. Often, the time it takes to update the connection can come at the expense of the user experience. Connection subrating achieves a power-saving low duty cycle in a different way and can switch to a high duty cycle faster than a non-subrated connection. Subrated connections are also able to handle variable packet rates or bursty traffic more efficiently. The ability to switch quickly from a low duty cycle connection to a high duty cycle connection when required will provide an improved user experience for some important product types.
Use cases expected to benefit from subrated connections include Bluetooth LE Audio products such as hearing aids and Bluetooth monitoring systems which use sensors.
Channel Classification Enhancement
Bluetooth Low Energy (LE) Peripheral devices can now perform channel classification and influence the channel map used for adaptive frequency hopping, increasing connection reliability in certain situations.
Enabling Bluetooth LE Peripheral devices to influence the adaptive frequency hopping (AFH) channel map can improve the throughput and reliability of connections where Central and Peripheral devices are not in close proximity.
When two Bluetooth® enabled devices are connected, a spread spectrum technique called adaptive frequency hopping (AFH) is used. Bluetooth technology divides the 2.4GHz (ISM) frequency band into smaller channels and rapidly hops between those channels when transmitting packets. Channels are chosen using a channel selection algorithm and a table of data called the channel map which classifies each channel as either used (suitable for use) or unused (not suitable for use).
Prior to version 5.3 of the core specification, Bluetooth Low Energy channel classification was performed only by the Central device. However, if two connected devices are not in close proximity with each other, the radio conditions of the Peripheral device may differ from those experienced by the Central. Consequently, when channel classification is performed only by the Central device, it is possible that the channel map can contain channels classified as used which are not a viable choice for the remote Peripheral. This can increase the chance of packet collisions and has the potential to degrade throughput.
Channel classification in Bluetooth LE may now be performed by the Peripheral device as well as the Central. The Peripheral can report its channel classifications to the Central device so they too can be considered when updating the Central device’s channel map. The channel classification enhancement enables both devices to determine which channels are performing well and suitable for use, reducing the likelihood of packet collisions and boosting throughput and reliability.
All Bluetooth Low Energy (LE) connected devices can benefit from Peripheral devices now being able to perform channel classification and influence the AFH channel map.
Removal of the Alternate MAC and PHY (AMP) Extension
The Alternate Media Access Control and Physical layer extension (AMP) allows a Bluetooth system to include one or more secondary controllers alongside a primary Bluetooth BR/EDR controller. Secondary controllers allow the use of the IEEE 802.11 MAC and PHY protocols instead of the standard Bluetooth layers that are part of the primary controller.
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. Members will still be able to qualify products that use AMP against an earlier version of the Bluetooth Core Specification until further notice.