What’s new in Bluetooth®︎ Core 6.2: An overview

What’s new in Bluetooth®︎ Core 6.2: An overview

The Bluetooth SIG recently adopted Bluetooth® Core 6.2, which brings exciting new features and improvements for Bluetooth products. A standout feature included is undoubtedly Bluetooth® Shorter Connection Intervals (SCI), which introduces a new range of connection intervals below 7.5 ms. This enables ultra-low-latency Bluetooth LE applications that can have report rates exceeding 2 kHz over a secure connection - something that many Bluetooth developers and consumers have been eagerly awaiting.

This blog post will cover the features introduced in Bluetooth® Core 6.2, focusing on the details about Bluetooth® SCI and its potential applications.

We are also proud to share that Nordic has been a major contributor to the enhancements and a key driver of the SCI feature. Our team received an award from the Bluetooth SIG for the SCI IOP validation efforts, including “outstanding contributions to the validation of the Bluetooth® Core 6.2 enhancements, having contributed more than 35% of the results entered”. The list of awards can be found at Awards and recognition on the Bluetooth® Technology website. Congratulations to all award recipients and nominees!

Bluetooth® Shorter Connection Intervals

The Bluetooth®︎ Shorter Connection Intervals feature, released as part of Bluetooth® Core 6.2, adds two important improvements related to Bluetooth LE connections:

  • Configuration of LE ACL links with shorter connection intervals
  • LE Flushable ACL Data

Bluetooth®︎ SCI enables connection intervals that are shorter than 7.5 ms, which has been the lower limit for connection intervals in the Bluetooth®︎ Core Specification up until this latest release. To be exact, SCI extends the connection interval range to span from 375 µs to 4.0 s and defines the resolution to be a multiple of 125 µs. This range is called the Extended ConnInterval Values (ECV). Additionally, two subset ranges are defined:

  • Rounded ConnInterval Values (RCV)
  • Baseline ConnInterval Values (BCV)

RCV is defined as all values of ECV that are multiples of 1250 µs in resolution, and BCV is defined as all the values of RCV that are equal to or above 7.5 ms. The figure below illustrates the different ranges in a more comprehensible way, and from there, it is easy to see that the BCV corresponds to the same range of connection intervals as defined prior to Bluetooth®︎ Core 6.2, and it is the default range of connection intervals when Shorter Connection Intervals is not supported.

New connection interval ranges as defined in the Bluetooth 6.2 specification

If the Bluetooth Controller supports the SCI feature, it must support all values of RCV (1.25 ms to 4.0 s with 1.25 ms resolution). Optionally, it can also support any other value from the ECV; the supported values should be indicated by the Controller. If SCI is not supported, the Controller needs to support all values of BCV but not any other value. The table below shows a summary of the value ranges.

Value Range Description Min. Interval (ms) Resolution (ms)
BCV Default range when SCI not supported ≥ 7.5 multiples of 1.25
RCV Mandatory range when SCI supported ≥ 1.25 multiples of 1.25
ECV Optional extension range when SCI supported .375 – 1.25 multiples of 0.125

A Controller that supports SCI also needs to support the Connection Subrating feature. Moreover, to take full advantage of Bluetooth®︎ SCI, it should also support Frame Space Update (FSU) to optimize the time between adjacent transmissions, T_IFS, which can be negotiated to values below 150 µs starting from Bluetooth®︎ Core 6.0. You can read more about the Connection Subrating feature in the following document by the Bluetooth SIG: Bluetooth®︎ Core 5.3 Feature Enhancements, and about FSU in the Bluetooth®︎ Core Specification 6.0. Noteworthy fact: FSU was authored by Nordic Semiconductor!

When forming a new connection, the default connection interval must be in the BCV range. The connection interval can then be updated to the ECV range, that is, to a short connection interval, using either the newly defined Connection Rate Update procedure from the Central side or the Connection Rate Request procedure from the Peripheral side. The Central can reject the Connection Rate Request procedure.

The second feature, LE Flushable ACL Data, allows data packets to be dropped if they are marked as flushable by the Host, and if the packet in the transmission queue is older than the specified flush timeout. If we consider a Human Interface Device (HID) mouse as an example, the LE Flushable ACL Data packet would be useful, for example, when input data from the mouse is being retransmitted due to interference, but after a certain time, some data that’s next in line in the transmission queue becomes invalid due to not being relevant anymore. Marking the data as flushable would improve the responsiveness of the mouse, as there is now no need to transmit outdated data packets. Note that the packets that have been transmitted but not yet ACK’d must be retransmitted until they are ACK’d and thus cannot be flushed - only packets whose Flush Timeouts exceed before their first transmit opportunity can be flushed.

Potential applications for Bluetooth®︎ SCI

Reaching connection intervals lower than 7.5 ms can be beneficial for a variety of applications. The shorter connection intervals and flushable HCI ACL Data can be especially significant for HID products that require ultra-low latencies, such as gaming mice and keyboards, as well as pen tablets and styluses. Until now, Bluetooth LE gaming accessories have typically been limited to roughly 125 Hz polling rates, which may not be sufficient for all gamers. However, with the features in SCI, the polling rates could theoretically reach over 2 kHz. HID devices supporting SCI could, in practice, provide polling rates between 1 and 2 kHz, as some overhead is required for processing the reports and handling the Bluetooth stack.

This major improvement in connection interval lengths makes Bluetooth LE gaming mice and keyboards more tempting than ever for both competitive and casual gaming, due to the fact that the latency arising from Bluetooth connections with intervals equal to or longer than 7.5 ms has previously been viewed as the biggest hurdle between proprietary 2.4 GHz and Bluetooth for intensive gaming. Typically, 1000 Hz polling rates are considered sufficient for even the most demanding and high-speed FPS games, not only among casual gamers but also professionals, to provide smooth cursor movement and input reporting without dropping pixels or frames. Bluetooth mice and keyboards have a clear advantage over proprietary protocols in that they do not require a proprietary 2.4 GHz dongle, given that the host device supports Bluetooth LE. Bluetooth also offers inherent advantages in terms of interference mitigation, low power consumption, and, by extension, improved battery life, as well as enhanced interoperability and compatibility.

In addition to HID, Bluetooth®︎ SCI could also be useful in other applications that require frequent updates with low latency over a connection, such as real-time high-accuracy positioning, time-critical edge AI applications that require ultra-fast responses, or precision sports performance tracking devices. Similar update rates of 1-2 kHz can be utilized in applications with high-performance modes, where measurements are gathered at short intervals and processed in real-time for higher accuracy, improved error mitigation, and faster response times.

Additional features in Bluetooth®︎ Core 6.2

Bluetooth Core 6.2 also introduces the following features:

  • Channel Sounding Amplitude-based Attack Resilience
  • HCI USB LE Isochronous Support
  • LE Test Mode Enhancements
  • Security and Privacy Mandates (Batch 2)

Channel Sounding Amplitude-based Attack Resilience is part of the ongoing work to provide improvements to Bluetooth®︎ Channel Sounding, this time focusing on security. This feature provides an additional layer of security that complements the phase-based attack resilience, utilizing the amplitude-based Normalized Attack Detection Metric (NADM).

HCI USB LE Isochronous Support introduces a method for serializing and transporting different HCI packets over LE Isochronous Channels using the USB Transport Layer. This adds an optional Bulk Serialization Mode to the USB Transport Layer in addition to the legacy mode. In Controllers supporting the Bulk Serialization Mode, an alternate USB endpoint is used, where all commands and data from the Host to the Controller are serialized on one endpoint, and all data from the Controller to the Host is serialized on a different one. In contrast, in the legacy mode, there are separate endpoints for commands, events, data, and eSCO.

LE Test Mode Enhancements bring a Unified Test Protocol (UTP) feature for performing Low Energy RFPHY measurements. And finally, the Security and Privacy Mandates (Batch 2) update brings new requirements to security and privacy implementations. It is a set of four errata to improve Bluetooth security, via improving the passkey generation implementations of Secure Simple Pairing, BR/EDR Secure Connections, LE Legacy Pairing, and LE Secure Connections Pairing, and mitigating reflection attacks on LE Legacy Pairing.

Closing

Bluetooth® Core 6.2 is now out, and it brings many exciting new features, including Bluetooth®︎ Shorter Connection Intervals, which Nordic has been actively driving, bringing Bluetooth developers and consumers the capability to reach ultra-low latencies under 7.5 ms on Bluetooth®︎ LE Secure Connections. Additional security, test, and HCI enhancements were also released as part of Bluetooth®︎ Core 6.2. If you find these updates interesting, please remember to subscribe to the Nordic DevZone blog posts by clicking the Subscribe button below.

Further reading:

  • Hi,

    Google Find Hub network support is available in nRF Connect SDK from v2.7.0 onwards. New projects can be started using the Fast pair locator tag sample as a starting point. There is no public API for fetching location data, it is only available to the end-user for security purposes.

    Please see the following link for the Find Hub Network Accessory Specification and registration.

    Our support should be able to help you with the approval and registration process. Have you already had your questions answered in the private ticket? If not, please let us know.

  • @Joel Kauppo or anyone from Nordic,

    I have a question regarding Google Find My Device / Find Hub SDK access.

    We are developing an ultra-small BLE tag (MicroTag) under SONYROID Co., Ltd. (Project ID: 59106960746) and I need to understand the exact process to obtain the Find My Device SDK and API from Nordic.

    Specifically:
    1. What is the approval process? Do we need Google's approval first, or do we request from Nordic directly?
    2. Is there a public API for backend to fetch location data, or is the location data only available to the end-user on their phone?
    3. I already submitted a private ticket. Will Nordic provide the SDK access through that, or do I need to contact someone specific (e.g., Brian Ha)?

    Any guidance would be greatly appreciated. Thank you!

  • Hello, I have some questions. If we update the interval to the minimum value (375us), what is the maximum amount of ACL data we can send?
    If the data is too long (such as sending a control packet), will we encroach on the next interval?
    If not, does that mean we can never send overly long packets? For example, for a CONNECTIN RATE IND , would we be unable to update the interval to a larger value?
  • The changes about legacy passkey pairing can be found in Table 2.8 in the Security Manager specification.

    Notably, legacy passkey pairing is no longer considered "authenticated", meaning that it no longer satisfies Security Mode 1 Level 3.