Bluetooth 6 explained: release dates, Channel Sounding and real-world adoption

The public announcement of Bluetooth 6.0 was on September 3, 2024. The specification's version history records August 27, 2024 as the date of adoption by the Bluetooth SIG Board of Directors. These dates describe different events: approval of the specification and its public announcement.

Scroll horizontally if the table does not fit.

Bluetooth 6.x adoption dates, release announcements and major changes

Version	Adopted	Released / announced	Major changes
6.0	2024-08-27	2024-09-03	Channel Sounding; improvements to discovery, audio transport and frame spacing
6.1	2025-05-05	2025-05-06	Randomized timing of private address updates
6.2	2025-11-03	2025-11-04	Shorter connection intervals, ranging attack resilience and LE audio transport over USB
6.3	2026-05-05	2026-05-06	Improved ranging phase correction, accuracy capability reporting and HCI extensions

From 6.1 onward, updates followed a twice-yearly release cycle. There is no need to equate that schedule with how often you replace a phone. Revisions add capabilities and procedures that designers can implement. Devices already on sale do not all become unusable when the next revision is announced.

A retail specification that says only "Bluetooth 6" does not tell you which additional 6.x features are enabled. We will first examine the foundations added in 6.0, then distinguish what later revisions change.

Channel Sounding is a prominent addition in 6.0. Two connected Bluetooth LE devices exchange radio signals to obtain measurements used to estimate the distance between them. Within a measurement step, the device that transmits first is the Initiator; the responding device is the Reflector. A Reflector is an active radio device that receives and responds, not a passive surface such as a wall or mirror.

The transmission order within a step is separate from requesting the overall measurement procedure. Either role can request that the procedure start. Nor is there a fixed mapping between the LE connection roles, Central and Peripheral, and the ranging roles, Initiator and Reflector.

Proximity estimates based on received signal strength, or RSSI, existed long before this. But a weak signal does not necessarily mean a device is far away. A person's body or furniture can block it; device orientation and reflections also matter. Estimating a speaker's distance from loudness alone faces a similar problem: their voice and any intervening walls affect what you hear.

Rather than relying only on strength, Channel Sounding uses Phase-Based Ranging (PBR) and Round-Trip Timing (RTT). These ranging methods can be used individually or together. The specification defines the signal exchanges and the handling of measurement results. It does not prescribe one final distance-estimation algorithm for every implementation.

That is why "Bluetooth 6.0" cannot guarantee an error of a particular number of centimeters. Antennas, calibration, estimation algorithms and the environment can change the result even when devices support the same feature. Specification compliance and a product's ranging performance need separate checks.

A radio wave repeats in cycles. Phase describes where it is within a cycle. Changing the frequency changes the wavelength, so the phase at arrival changes even over the same path. PBR uses phase changes measured across multiple frequencies as evidence about distance.

A single phase measurement, however, cannot tell you how many complete cycles have passed. Looking at the hands of a clock does not tell you how many days have elapsed. Measuring at several frequencies helps deal with this repeating ambiguity while extracting the changes associated with distance.

After one full cycle, the phase repeats

0

1

2

At 0, 1 and 2 full cycles, the phase is the same.

PBR also uses how phase changes as frequency changes. Distance estimation uses two-way measurements and corrections, including those for oscillator offsets.

Propagation delay is not the only influence on measured phase. Each device has its own oscillator, and their relative offset is part of the measurement too. Implementations therefore use two-way measurements and corrections. This is not a single step that directly converts the phase of a wave sent by one device into distance.

Scroll horizontally if the table does not fit.

Different measurements provide different evidence

Method	Main observation	Important limitation
RSSI estimation	Received signal strength	Obstructions and orientation affect it as well as distance
PBR	Phase changes as frequency changes	Repeating phase, oscillator offsets and reflected paths must be handled
RTT	Signal round-trip time	Response and circuit delays must be separated from propagation time

Indoors, a receiver gets signals reflected by walls and other objects as well as signals arriving directly. These multiple paths are called multipath. Measurements across frequencies or antenna paths can help, but they do not make obstacles irrelevant. A claim of centimeter-level accuracy needs the accompanying environment, distance and success-rate conditions.

RTT estimates distance from the time a signal takes to travel out and back. Yet the time between A sending and receiving also includes the time B takes to respond. That response delay must be separated from the time spent traveling through space.

RTT separates round-trip travel time from the response delay

A

B

A: transmits first in this exchange (Initiator)
B: responds (Reflector)

Green diagonal lines: radio propagation
Rust-colored vertical line: response delay at B
Time runs from top to bottom. Neither distance nor time is drawn to scale.

One-way distance ≈ speed of light × (elapsed time measured at A − response delay at B) ÷ 2

Consider a simplified editorial calculation. With the speed of light approximated as 300 million meters per second, traveling 1 m takes about 3.33 ns one way, or 6.67 ns for the round trip. A nanosecond is one billionth of a second. An error of just 1 ns in the estimated round-trip travel time corresponds to about 15 cm in the distance estimate.

This example does not predict a product's measurement error. It illustrates why ranging needs precise timing and corrections at the radio level. Timing a phone app's send API call and reply callback with a stopwatch also captures OS scheduling and other delays; that is not the same measurement.

Combining PBR and RTT gives implementations different kinds of evidence for dealing with distance ambiguity or suspicious measurements instead of trusting only one observation. Ranging still does not solve every security problem. For a digital key, being nearby and being authorized to unlock are separate conditions that must both be checked.

Introductions to Channel Sounding have discussed the prospect of accuracy around 10 cm. For example, the SIG-hosted article from November 2023 covers performance before the specification was finalized. Its figures cannot be treated as a guarantee for every current product. The technical overview also explains that the standard does not specify the distance-estimation algorithm. A specification name is not a universal accuracy guarantee.

The figure of approximately 150 m also needs context. With PBR frequency steps of 1 MHz, it describes a distance-ambiguity boundary associated with phase repetition. It does not guarantee that an ordinary tag can be found from 150 m away, much less with centimeter-level accuracy at that range. Transmit power, receiver sensitivity, antennas and surroundings also affect usable range.

Distance is not position, either. Knowing that an object is 2 m from a phone does not tell you whether it is to the left, to the right or behind a wall. Determining direction or placing it on a map requires other observations or processing. A distance-reading illustration should not be read as a promise that every product can display a direction arrow.

Knowing it is 2 m away does not tell you which way to look

Center: the phone
Purple dots: examples of possible peer locations

Each candidate is the same 2 m from the center. Distance alone cannot choose between them.

Finding direction or position requires additional observations or processing.

Ultra-wideband (UWB) is also used for nearby ranging, but it is a different radio technology from Bluetooth Channel Sounding. Android's ranging API treats them as separate methods. Overlapping use cases do not make them interchangeable. A UWB tag connecting to a Bluetooth 6 phone does not, by that fact alone, turn into a Channel Sounding ranging device.

For a practical comparison, check the supported phone, app, peer device, environment and battery life as a complete combination rather than asking only "UWB or Bluetooth?" This article does not rank vendors' accuracy by placing demonstrations with different test conditions side by side.

Ranging is not the whole update. Bluetooth LE devices use advertising packets to announce their presence or information. Following every related packet can waste reception time. Decision-based Advertising Filtering lets a scanner use the initial information to decide whether to follow the associated additional packets. "Advertising" here means radio announcements, not on-screen advertisements.

Monitoring Advertisers helps the host know whether a device of interest can still be observed. Filtering duplicate notifications can save power, but a device found earlier may no longer be nearby. The improvement addresses the need to reduce notifications while still knowing the peer's status.

For audio transport, 6.0 improves the Isochronous Adaptation Layer, or ISOAL, which organizes data into units suitable for transmission. A new framing mode aims to reduce delays associated with fragmenting data, among other benefits. It does not replace the audio codec itself, and the number 6.0 does not determine sound quality.

The update also lets compatible devices adjust frame spacing within a connection instead of always using the previous fixed 150 µs gap. This is different from the shorter connection intervals introduced in 6.2. Think of the difference between reducing gaps between railway cars and running trains more frequently: the interval being changed matters.

6.0 and 6.2 change different intervals

6.0: from one packet's end to the next packet's start

Green bracket: frame spacing. Previously fixed at 150 µs; now adjustable.

6.2: from one connection event's start to the next event's start

Rust-colored bracket: connection interval. SCI lowers its minimum.

6.1: change when an address updates, not just the address

Bluetooth LE can use Resolvable Private Addresses (RPAs) to avoid continually broadcasting a fixed identifier. Randomized RPA Updates in 6.1 vary the update timing, making regular update times less useful as a tracking clue. Handling updates in the controller can also save power.

This does not make every form of tracking impossible. Information sent by an app, identifiers held by a service and location access granted by a user are separate layers. Changing the name on a door does not prevent someone identifying themselves elsewhere. One privacy mechanism should not be expanded into a promise of complete anonymity.

6.2: 375 microseconds is a conditional minimum, not total latency

Shorter Connection Intervals (SCI) reduce the time between communication opportunities on an LE connection. Compared with the legacy minimum of 7.5 ms, the required SCI range starts at 1.25 ms, and an optional extended range reaches 375 µs. Support for 375 µs is not mandatory for every SCI-capable device.

A shorter interval between communication opportunities

Legacy minimum: 7.5 ms
Baseline for connections without SCI

Minimum in the required SCI range: 1.25 ms
RCV: mandatory range when SCI is supported

Minimum in the optional SCI range: 0.375 ms
ECV: additional support and conditions must be checked

Because 7.5 ms ÷ 0.375 ms = 20, those two interval minima differ by a factor of 20. That does not mean game inputs become 20 times faster or audio latency becomes 375 µs. Input sampling, OS processing, queues, retransmission, audio encoding and playback still take time. Choosing shorter intervals also involves trade-offs in power consumption and radio congestion.

Version 6.2 also adds resilience against attacks that manipulate ranging-signal amplitude, LE isochronous transport when the host and controller are connected over USB, and radio-test improvements. Shorter connection intervals do not describe the whole revision.

6.3: improve ranging corrections and capability reporting

Inline PCT Transfer in 6.3 adds a mechanism for the Reflector to compensate phase in its response. It builds on two-way measurement and correction while reducing the burden of transferring and processing measurement results. Both endpoints must support and enable the feature.

Devices can also report RTT accuracy capabilities separately for each PHY, or radio physical-layer mode. The revision includes expansions to HCI command and event representations as well. These are improvements for combining implementations correctly, not a headline promise that every 6.3 device is some fixed multiple more accurate.

Official documentation establishes that Bluetooth 6 has reached consumer phones, and that evaluation examples combining phone apps with development kits are available. It does not establish the total number of Bluetooth 6 devices in use or the share of people using Channel Sounding every day. This article does not estimate market share or an adoption percentage in Japan or elsewhere.

Scroll horizontally if the table does not fit.

Examples documented by official sources, and what they do not establish (reference date: November 10, 2026)

Example	Documented information	Not established by that information alone
Apple iPhone 17	Bluetooth 6 in the specifications; UWB listed separately	Every additional 6.x feature or Channel Sounding with arbitrary tags
Google Pixel 10	Bluetooth v6 with antenna diversity in the specifications	Compatibility with every ranging app and peer device
Samsung Galaxy S26 UK model SM-S942BLBHEUB	The checked official specification lists Bluetooth v5.4	The specifications of other models or regional variants
Ranging API, Android 16 and later	An API covering BLE Channel Sounding, BLE RSSI, UWB and Wi-Fi RTT	Hardware for every method in every Android 16 phone
Nordic nRF54L15 DK	Initiator and Reflector samples can be tried with two development kits	A ready-to-use retail tag or guaranteed compatibility with every phone
Pixel 9/10 with nRF Toolbox	Nordic documents ranging with an nRF54L15 DK; the OS, app and SDK requirements are explained below	Support for consumer item-finding services or guaranteed accuracy in every device and environment

Examples such as the iPhone 17 and Pixel 10 do not mean every new phone uses version 6. Conversely, the existence of 5.x products does not mean 6 has yet to reach products. Several generations coexist in the same market.

For the nRF54L Series, Nordic documents Channel Sounding support with a qualified host and controller from nRF Connect SDK 3.0.1 onward. That demonstrates an available development foundation. It is not the same as a consumer buying a tag and registering it with an existing item-finding service.

More specifically, Nordic publishes a development and evaluation procedure using a Pixel 9 or 10 with an nRF54L15 DK. The setup uses Android 16 QPR2, nRF Toolbox 4.1.4 or later and nRF Connect SDK 3.0.1 or later. The DK runs the Reflector sample built with android_ranging.conf. After the phone connects and pairs, the app uses the phone's ranging capability to display distance. This is a vendor-documented example, not a NanToo hands-on test. The guide also discusses Android 17; this article uses the stable QPR2 configuration as its example rather than generalizing individual beta-version results to every OS release.

Android provides an API, but its guide calls for checking both device capabilities and their current availability. Software should not assume a feature exists solely from the OS version. A phone's specification sheet and an OS API guide answer different questions; neither substitutes for the other.

There are also restrictions on when it can be used. For third-party apps using Android's Ranging module, background ranging is limited to UWB on supported devices; it is not allowed for Channel Sounding. Checking distance with an app in the foreground is different from continuously ranging while using other apps. This is a restriction of that Android API, not a claim that the same rule applies to every manufacturer's system feature or to all embedded devices.

From a Bluetooth 6 label to a distance reading

Phone
Compatible radio

Peer device
Compatible radio

Both endpoints support Channel Sounding

Firmware and OS
Enable the feature and handle measurement data

App and service
Range with a supported peer, then obtain and display results

Conditions during use
Permissions, settings, radio conditions and foreground use

Third-party apps using Android's Ranging module cannot perform Channel Sounding ranging in the background. Hardware support does not mean continuous ranging is available.

Our editorial assessment is therefore that Bluetooth 6 is in real products and Channel Sounding can be evaluated with specific combinations, while support in consumer item-finding services still needs case-by-case checking. Something a developer can evaluate is not necessarily something a retail tag will do immediately in your usual app.

Does Bluetooth 6 sound better?

Sound-quality comparisons need the codec, profile, support at both ends and the actual connection settings. LE Audio, LC3 and Auracast are not alternative names for Core 6.0. Our separate Bluetooth LE Audio and Auracast article (in Japanese) covers those topics.

Will older devices stop connecting?

A newer version does not impose a blanket ban on communicating with older devices. Both ends still need a compatible radio mode, profile and feature set. Being able to connect does not mean every new feature is available. Older headphones do not automatically gain ranging or a new audio system merely because they connect to a newer phone.

Can a software update turn a device into Bluetooth 6?

Some capabilities can be enabled by updates. Software cannot add every feature to hardware that lacks the required radio circuitry or timing control. Check whether the manufacturer explicitly names the model and features it will support. A chip's theoretical capability is not a promised product update.

Should you avoid 6 now that 7.0 has arrived?

On November 4, 2026, Bluetooth SIG announced adoption of HDT, an optional feature of Core 7.0. Announcing a new specification does not replace everything on store shelves that day. Choosing a product that meets your needs and following future specifications are different decisions. This article keeps 7.0 features separate from the 6.x revisions.

Start with one task you want to accomplish. Listening to music calls for checking audio features; finding keys calls for checking the item-finding service and ranging method; a low-latency input device calls for checking its behavior in the intended connection mode. Trying to judge all of these with a single Bluetooth version number invites mistakes.

• Specification: Is the required feature named separately from the Bluetooth version?
• Peer: Does the documentation identify your combination of phone, PC or tag?
• Software: What are the minimum OS, app and firmware requirements, and when are they available?
• Performance: Do accuracy and latency figures identify the test conditions and the quantity being measured?
• Availability: Can you distinguish a shipping product, a development kit and a promised future update?

Developers should also decide how to handle failed or unreliable measurements. In an unlocking application, should one momentarily short distance estimate be enough to grant access? How should uncertainty or suspicious results be treated? Adopting the standard does not answer those design questions automatically.

The value of Bluetooth 6.x is not simply that its version number increased. It offers more detailed ways to interact with nearby devices. Version 6.0 added the ranging foundation and other improvements; 6.1 changed address updates; 6.2 improved connection intervals and security; and 6.3 refined ranging corrections and capability reporting.

A specification is a shared language for design. A product implements it. The user experience also depends on the peer device and software. Once these three layers are separated, "6 is only starting to spread, yet 7 is here" is no contradiction. New specifications can progress while earlier generations of implementations and services expand. That timing gap is part of understanding Bluetooth's evolution.