Bluetooth® Core 6.3 technical overview

1. Introduction

Bluetooth® Core Specification v6.3 (Bluetooth® Core 6.3) includes several feature enhancements. This paper provides an overview of each enhancement.

Note: This is a marketing document and is not intended to replace or overrule the Bluetooth® Core Specification in any way. Each feature enhancement is described in a dedicated section, beginning with relevant background information. This is intended to assist readers who may be unfamiliar with certain aspects of Bluetooth® LE. However, the background sections are not fully comprehensive. Readers who encounter unfamiliar terminology or concepts are encouraged to download and read the Bluetooth® LE Primer.

2. At a glance

A suite of targeted enhancements has been introduced to advance the capabilities of Bluetooth® technology. These updates improve high-precision ranging, enable more granular performance reporting, future-proof the Host Controller Interface (HCI), and harmonize Radio Frequency (RF) requirements to reduce design complexity and power consumption.

2.1 Bluetooth® Channel Sounding Inline PCT Transfer

Bluetooth® Channel Sounding Inline PCT Transfer enhances Bluetooth® Channel Sounding accuracy and efficiency by allowing the reflector to transfer phase-aligned tones directly into hardware. It modifies the Bluetooth® Channel Sounding procedure by adjusting the phase of the tone at the reflector. The reflector ceases reporting the imaginary (Q) component of the Phase Correction Term (PCT) values over HCI. This change optimizes performance by eliminating excess result data, reducing overhead, and improving the speed and efficiency of the Bluetooth® Channel Sounding procedure, particularly in Ranging Service (RAS)/Ranging Profile (RAP) contexts.

2.2 Bluetooth® Channel Sounding PHY-specific RTT Accuracy

Bluetooth® Channel Sounding PHY-specific RTT Accuracy enables devices to declare Round-Trip-Time accuracy separately for each PHY rather than relying on a single value across all modes. By introducing new PHY-specific Round Trip Time (RTT) parameters and an expanded capability structure, systems can select the optimal PHY-accuracy combination, improving precision, performance scaling, and interoperability in multi-PHY ranging scenarios.

2.3 Bluetooth® Running Out of Bits

Bluetooth® Running Out of Bits extends the architectural limits of the HCI by expanding the Supported Commands bitmask from 64 to 251 octets and the LE Event Mask from 8 to 255 octets. It provides the necessary protocol capacity for future feature growth, ensures discoverability of newly assigned commands and events, and maintains backward compatibility through versioned commands and conditional support rules.

2.4 Bluetooth® ACP and C/I Limit Relaxation

Bluetooth® ACP and C/I Limit Relaxation harmonizes RF requirements between Bluetooth® Classic (Basic Rate/Enhanced Data Rate, BR/EDR) and Bluetooth® LE by aligning BR/EDR Adjacent Channel Power (ACP) and Carrier-to-Interference (C/I) limits with the LE 1-MS/s framework. The updated limits relax unnecessary constraints on Bluetooth® Dual-Mode radios supporting both Bluetooth® BR/EDR and Bluetooth® LE, simplify transmitter and receiver design targets, and enable more power-efficient, flexible RF architectures without compromising coexistence performance.

3. Bluetooth® Channel Sounding Inline PCT Transfer

3.1 Background

Phase-Based Ranging (PBR) in Bluetooth® Channel Sounding estimates distance by measuring phase shifts across multiple frequencies. The core relationship comes from the propagation delay τ = 2d/c:

θ(f) = 2πfτ = 2π(2df/c)

Thus, the phase shift θ(f) is proportional to the round-trip distance 2d and the frequency f.

In practice, because the initiator and reflector each use independent local oscillators (LOs), the measured phase includes a device-specific offset unrelated to the physical channel. The observed phase at the receiver, therefore, consists of:

  1. Channel-induced phase θCH(f) — The phase shift is caused purely by signal propagation through the air. This is a useful component that contains the distance information d.
  2. LO-relative phase offset ΔθLO(f) — A systematic offset arising from the phase difference between the initiator and reflector’s LOs. This offset carries no distance information and must be eliminated. The LO-relative offset is defined as:
    ΔθLO(f) = θLO,Initiator(f) − θLO,Reflector(f)

And the measured phases in a two-way exchange become:

  • Reflector’s measurement: θREFL(f) = θCH(f) + ΔθLO(f)
  • Initiator’s measurement: θINIT(f) = θCH(f) − ΔθLO(f)

Bluetooth devices, while running a PBR signal exchange, should strive to recover the Channel-induced phase while eliminating the LO-relative phase offset. This approach enables the devices to produce more precise phase data, resulting in more accurate distance measurements.

3.2 Traditional two-way phase cancellation (digital post-processing)

The Bluetooth® Channel Sounding Inline Phase Correction Term (IPT) Transfer feature enhances distance measurement accuracy and efficiency by refining phase data precision. At the highest level, high-precision ranging depends on the integrity of the Phase Correction Term (PCT). IPT allows the reflector to perform inline analog phase pre-compensation, effectively neutralizing Local Oscillator (LO) offsets in real-time before the initiator even measures the signal. By transferring a “cleaner” phase component, IPT reduces the potential for digital processing errors and LO drift to degrade the final distance calculation. Furthermore, it reduces data overhead and improves ranging speed, enabling more CS procedures within a given time.

Without IPT, Bluetooth® Channel Sounding removes LO offset through a two-way measurement and digital cancellation. The procedure is listed below:

  1. Reflector’s measurement (forward path)
    The reflector receives the signal from the initiator and measures its phase:
    θREFL(f) = θCH(f) + ΔθLO(f)
  2. Initiator’s measurement (return path)
    The initiator receives the reflected signal and measures its phase:
    θINIT(f) = θCH(f) − ΔθLO(f)
  3. Digital cancellation
    The initiator sums both PCTs:
    θREFL(f) + θINIT(f) = 2θCH(f)
    The ΔθLO(f) terms cancel out, yielding the pure, doubled channel phase required for distance estimation.

And the limitations of this traditional method are:

  • Post-processing latency — Cancellation occurs in the digital domain after both measurements are collected.
  • Data overhead — The reflector must report full complex PCTs (I and Q) for every tone and antenna path via HCI events, resulting in high control-plane data overhead.
  • Algorithm complexity — The initiator must combine two measurements to recover 2θCH(f).

3.3 Inline PCT Transfer (IPT): Inline analog phase pre-compensation

The Bluetooth® Channel Sounding IPT Transfer feature introduced in this Change Request moves LO offset cancellation from the digital domain to the reflector’s analog frontend.

The reflector immediately uses its measured phase θREFL(f) to adjust the phase of its outgoing tone, effectively coherently forwarding the received phase.

3.3.1 Phase flow with IPT enabled
  1. Reflector measurement (unchanged)
    θREFL(f) = θCH(f) + ΔθLO(f)
  2. Reflector transmission (Key change)
    Instead of transmitting with its own LO phase (θLO,R), the reflector retransmits with a phase aligned to the received signal:
    φTX,R = θLO,I + θCH(f)
    The reflector does not need knowledge of the initiator LO; coherent forwarding causes LO terms to cancel.
  3. Initiator receives the IPT-compensated signal
    This phase-forwarded signal travels back through the channel (adding another θCH) and arrives at the initiator with absolute phase:
    φRX,I = θLO,I + 2θCH(f)
  4. Initiator baseband phase
    After down-conversion using its own LO (θLO,I), the initiator’s baseband phase is:
    θINIT,IPT(f) = 2θCH(f)
    The ΔθLO(f) term has been removed in the analog domain before the digital measurement.
  5. Reflector PCT reporting (simplified)
    Because the reflector has already applied its measured phase for compensation, it reports a PCT with zero phase (Q = 0). The I component carries only the signal amplitude. Meanwhile, the initiator’s PCT now contains the direct 2θCH(f) measurement.

3.4 Comparative analysis: Traditional vs. IPT-enabled

The table summarizes the phase flow and system behavior using absolute phase as the reference between the Traditional and IPT-enabled methods.

StepDescriptionTraditional (no IPT)IPT-enabledTechnical implication
1Initiator TXθLO,IθLO,IBaseline state.
2Reflector RXθLO,I + θCHθLO,I + θCHSame propagation.
3Reflector basebandθCH + ΔθLOθCH + ΔθLOSame measurement.
4Reflector TXθLO,RθLO,I + θCHFundamental difference: No IPT uses own LO. With IPT: coherently forwards received phase.
5Initiator RXθLO,R + θCHθLO,I + 2θCHIPT pre-advances the phase by θCH.
6Initiator basebandθCH − ΔθLO2θCHInitiator directly measures doubled channel phase; ΔθLO eliminated.
7Reflector PCT reportθCH + ΔθLO (Complex I/Q)Q = 0IPT simplifies Reflector’s report to amplitude-only (Q = 0).
8Effective 2-way phase2θCH (via digital sum)2θCH (direct measurement)Same result, different mechanism.

3.5 Technical benefits and implementation considerations

3.5.1 Technical benefits
  1. Simplified initiator processing — The initiator obtains a “clean” 2θCH(f) measurement directly, reducing algorithm complexity and latency.
  2. Reduced data payload — The reflector’s PCT is simplified (Q = 0), reducing per-tone HCI payload.
  3. Improved robustness — Compensation happens immediately in analog hardware, reducing sensitivity to LO drift during the exchange.
  4. Lower latency — Distance estimation can start immediately after initiator reception (no need to wait for the reflector’s PCT report).
3.5.2 Implementation considerations
  1. Reflector complexity — Reflector must support phase-coherent retransmission, requiring additional phase-tracking or phase-compensation hardware.
  2. Feature negotiation — IPT is a negotiable and configurable feature. Support is indicated in the LL_CS_CAPABILITIES exchange (IPT bit in [v2] PDUs) and enabled via the LL_CS_CONFIG_REQ PDU (IPT bit). A session uses IPT only if both devices support it and it is explicitly enabled on both devices.
  3. New timing parameters — The specification introduces companion timing parameters (T_IP2_IPT, T_SW_IPT) to accommodate potential processing differences when IPT is active. Antenna-switch durations are selected based on the enabled features of both peers.
  4. Backward compatibility — Devices that do not support Bluetooth® Channel Sounding Inline PCT Transfer continue to operate with the traditional two-way cancellation method. The feature is designed to be transparent to legacy initiators.

4. Bluetooth® Channel Sounding PHY-specific RTT Accuracy

4.1 Background

Bluetooth® Channel Sounding also incorporates a secondary ranging method called Round-Trip Time (RTT), which estimates distance by calculating the time-of-flight (ToF) of an RF signal transmission between devices. While RTT precision is fundamentally rooted in internal clock accuracy and timestamp resolution, the final achievable timing precision in a sounding session is determined by the number of CS_SYNC exchanges performed.

Prior to the Bluetooth® Channel Sounding PHY-specific RTT Accuracy enhancement, a device declared a single RTT accuracy requirement applicable to all PHYs. This requirement consisted of a specific time-of-flight precision target (e.g., 10 ns or 150 ns) and the minimum number of CS_SYNC exchanges required to achieve it. However, it did not account for PHY-specific performance characteristics. Different PHYs have distinct radio characteristics (e.g., symbol period and noise immunity) that directly affect RTT measurement accuracy. The previous uniform declaration model could lead to RTT-ranging challenges — such as requiring more exchanges than necessary and/or inaccurate ToF data — both of which can degrade RTT-distance measurement calculations.

This enhancement introduces a per-PHY RTT accuracy declaration mechanism, enabling devices to specify RTT performance separately for the LE 1M PHY and the optional LE 2M and LE 2M 2BT PHYs, thereby improving the distance measurement accuracy of RTT-based ranging.

4.2 Technical overview

4.2.1 New RTT accuracy parameters for LE 2M PHYs

Three new 1-octet parameters have been introduced to specify RTT performance for LE 2M and LE 2M 2BT PHYs:

  • RTT_2M_AA_Only_N: For AA-only mode on LE 2M PHYs
  • RTT_2M_Sounding_N: For standard sounding sequences on LE 2M PHYs
  • RTT_2M_Random_Sequence_N: For random sequences on LE 2M PHYs

Parameter details: Each parameter’s value determines its meaning:

  • Value = 0x00: Indicates that the corresponding RTT mode is not supported on LE 2M/2M 2BT PHYs.
  • Value = 0x01 to 0xFF: Specifies the number of CS_SYNC exchanges required to meet the precision requirements for that RTT mode.

Precision target clarification: When a parameter value is non-zero, the corresponding bit in the extended RTT_Capability field indicates the exchange count target:

  • 10 ns time-of-flight precision (bit = 1)
  • 150 ns time-of-flight precision (bit = 0)

If the parameter value is 0x00 (unsupported), the associated precision bit in RTT_Capability is ignored.

4.2.2 Host Controller Interface (HCI) enhancements

The HCI layer incorporates these new parameters through versioned commands and events to ensure backward compatibility.

New HCI [v2] commands and events:

  • HCI_LE_CS_Read_Local_Supported_Capabilities [v2]: Returns the local device’s capabilities, now including the three new LE 2M parameters and the expanded 6-bit RTT_Capability [v2] field.
  • LE_CS_Read_Remote_Supported_Capabilities_Complete [v2]: Reports the remote device’s capabilities.
  • HCI_LE_CS_Write_Cached_Remote_Supported_Capabilities [v2]: Allows the Host to write cached remote capabilities.

Key parameter updates:

To support higher data rates, the HCI now includes dedicated parameters for LE 2M PHY exchange counts (AA Only, Sounding, and Random Sequence). These complement the existing LE 1M parameters. Support for these [v2] versions is mandatory for devices implementing Bluetooth® Channel Sounding PHY-specific RTT Accuracy.

Backward compatibility and defaults:

For the HCI_LE_CS_Write_Cached_Remote_Supported_Capabilities command, a default logic ensures compatibility with legacy [v1] structures:

  • Legacy Command Support: If a [v1] command is used, it will not contain the specific fields for the LE 2M PHY.
  • Automatic Mapping: In this case, the Controller automatically populates the missing LE 2M parameters using the values provided for the corresponding LE 1M parameters.
4.2.3 Link Layer (LL) protocol updates

The Link Layer incorporates the same parameters through an enhanced PDU format, but with a different structural arrangement.

Enhanced LL PDU [v2] format:

  • The LL_CS_CAPABILITIES_REQ/RSP [v2] PDU format is extended to include fields for the three new LE 2M parameters.
  • The PDU includes an RTT-PHY indicator bit (in the Subfeatures_Supported field) that signals use of the per-PHY model.

Unlike the HCI sequence, the parameters in the LL PDU are interspersed within the CtrData structure according to the defined format.

4.3 Technical benefits and implementation considerations

4.3.1 Technical benefits

Optimized ranging efficiency: Devices can now perform the minimum necessary number of CS_SYNC exchanges for each specific PHY, reducing radio-on time and power consumption.

Granular precision targeting: By decoupling LE 1M and LE 2M declarations, systems can achieve higher precision (10 ns) on capable PHYs without being limited by lower-performing PHYs.

Improved interoperability: Explicitly declaring support for different RTT modes per PHY ensures more predictable performance in multi-vendor environments.

4.3.2 Implementation considerations

Mandatory HCI [v2] support: If a device implements Bluetooth® Channel Sounding PHY-specific RTT Accuracy, it must support the [v2] versions of the LE CS capability read/write commands.

Backward compatibility logic: The default behavior for “Missing Parameters” is mandatory. The Controller sets LE 2M parameters to the corresponding LE 1M values to ensure seamless operation with legacy hosts.

Extended PDU handling: The Link Layer must be updated to handle the enhanced LL_CS_CAPABILITIES PDU format, which intersperses the new parameters within the CtrData structure.

5. Bluetooth® Running Out of Bits

5.1 Background

The Host Controller Interface (HCI) is the standardized communication layer between a Bluetooth Host and a Bluetooth Controller. Commands are sent from the Host to the Controller, while events are sent from the Controller to the Host. The Bluetooth® Core Specification uses bitmask fields to declare and control support for these commands and events:

  • Supported_Commands: A bitmask returned by the HCI_Read_Local_Supported_Commands command, where each bit corresponds to a specific HCI command (1 = supported).
  • LE_Event_Mask: A parameter used by the HCI_LE_Set_Event_Mask command, where each bit controls whether a specific Low Energy (LE) event type is enabled for reporting to the Host.

As Bluetooth technology has evolved, especially with the rapid addition of Bluetooth® LE features, the available bits in these fields have been nearly exhausted. The original 512-bit limit on commands and the 64-bit limit on Bluetooth® LE events have become bottlenecks to adding new HCI commands and events in future specification updates.

5.2 Technical overview

5.2.1 New command versions

This new feature does not modify the existing commands. Instead, it introduces new “v2” variants with new OpCode Command Fields (OCF):

  • HCI_Read_Local_Supported_Commands [v2] (OCF: 0x0010): This new command returns the full 251-octet Supported_Commands bitmask. The original [v1] command (OCF 0x0002) continues to return only the first 64 octets. A new OCF is required because HCI command return parameters are version-bound; reusing the original OCF would require legacy Hosts to parse an extended return structure that they do not support.
  • HCI_LE_Set_Event_Mask [v2] (OCF: 0x00A4): This new command allows the Host to set the full 255-octet LE_Event_Mask. The original [v1] command (OCF 0x0001) only sets the first 64 bits (8 octets) of the mask; bits 64 and above remain unchanged when using the v1 command.
5.2.2 Backward compatibility and feature discovery
  • Conditional support:
    The v2 commands are optional for a Controller to implement, with the following critical conditions:These conditions ensure that, if a Controller uses extended features, the Host has the necessary tools to discover and control them.
    • A Controller must implement HCI_LE_Set_Event_Mask [v2] if it supports any event beyond the original bit allocation.
    • A Controller must implement HCI_Read_Local_Supported_Commands [v2] if it supports any command beyond the original bit allocation.
  • Command and event discovery:
    Checking support for a specific command depends on whether its support bit is in the original or extended block of the Supported_Commands field. Note that the command version (v1 vs. v2) is independent of the bit’s location.
    • Original Block (Octets 0–63): The support bits for the two new v2 commands are located within the original portion of the Supported_Commands field, specifically in Octet 49. Because these bits are in the original block, a Host can discover support for v2 commands by using the HCI_Read_Local_Supported_Commands [v1] command.
    • Extended Block (Octet 64+): To check support for any command located in the extended block, the Host must use the HCI_Read_Local_Supported_Commands [v2] command. If the Controller does not support this v2 command, it will reject the request with the error code Unknown HCI Command (0x01). This allows the Host to definitively determine that the Controller does not support the Running Out of Bits (ROOB) extended capabilities.
  • Version consistency:
    • Commands: The return parameters of a command always use the same version as the command that was executed. For example, the [v1] command returns 64 octets, while the [v2] command returns 251 octets.
    • Events: An HCI event always returns fields based on the highest version of the event that is both supported by the Controller and unmasked by the Host.
  • Default behavior preservation:
    The default event mask configuration remains unchanged, and all bits not explicitly listed or supported remain Reserved for Future Use (RFU).

6. Bluetooth® ACP and C/I Limit Relaxation

6.1 Background

The Bluetooth® Core Specification has evolved through multiple releases, leading to separate, increasingly divergent technical requirements for its two primary physical layer technologies: Bluetooth® Classic (Basic Rate/Enhanced Data Rate, BR/EDR) and Bluetooth® LE. Over time, the specification requirements for key RF performance metrics, most notably Adjacent Channel Power (ACP) and Carrier-to-Interference (C/I) ratio, have developed independently. This has resulted in discrepancies between the limits and test methodologies mandated for Bluetooth® BR/EDR and Bluetooth® LE radios.

Importantly, the Bluetooth® LE ACP and C/I requirements are unchanged by this enhancement.

The changes introduced in this feature focus exclusively on Bluetooth® BR/EDR, aligning its RF requirements with the existing LE 1 MS/s framework.

  • For ACP: Bluetooth® BR/EDR specifications impose emission limits at higher frequency offsets (e.g., > 3 MHz) that are approximately 15–17 dB stricter than those for Bluetooth® LE.
  • For C/I: The interference tolerance requirements for Bluetooth® BR/EDR receivers are tighter than those for Bluetooth® LE, especially when compared to Bluetooth® High Data Throughput (HDT) modes.

These inconsistencies create a challenge for designing modern Bluetooth® Dual-Mode radios that must support both Bluetooth® BR/EDR and Bluetooth® LE (including Bluetooth® HDT). To ensure compliance, designers are forced to meet the most stringent requirements of either standard, leading to over-constrained, sub-optimal designs.

This change resolves these inconsistencies by adopting a unified approach based on the LE 1 MS/s framework, which is suitable for Bluetooth® BR and EDR’s 1 MHz nominal-bandwidth signals.

6.2 Technical overview

This section breaks down the specific discrepancies and the proposed modifications for each key RF parameter.

6.2.1 Harmonization of Adjacent Channel Power (ACP) limits

Adjacent Channel Power (ACP) is a critical transmitter metric that quantifies power leakage into adjacent frequency channels. Its primary purpose is to ensure coexistence by minimizing interference with other Bluetooth links or wireless systems operating on adjacent frequencies.

The change applies the LE 1 MS/s ACP limits and test methodology to both Bluetooth® BR and EDR transmitters. The key updates are:

  • Relaxed limits for higher offsets: The absolute power limit for adjacent channels at offsets ≥ 3 MHz is relaxed from -40 dBm to -30 dBm, bringing it into alignment with the LE specification. The limit for the second adjacent channel at an offset of 2 MHz remains -20 dBm.
6.2.2 Alignment of Carrier-to-Interference (C/I) performance

The Carrier-to-Interference (C/I) ratio specifies a receiver’s ability to successfully demodulate a wanted signal in the presence of a strong interfering signal on a nearby frequency. It is the receiver-side complement to the transmitter’s ACP specification. A system-level balance is essential: there is minimal benefit in having an extremely clean transmitter if the receiver cannot tolerate practical levels of nearby interference.

The change adopts the text and methodology of the LE 1 MS/s C/I test while applying the appropriate Bluetooth® BR or EDR modulation for the interfering signal. Limits are adjusted based on the demodulation SNR required for each modulation type.

  • For Bluetooth® Basic Rate (BR – GFSK):
    • The wanted signal level for all tests is standardized to -67 dBm, simplifying test conditions.
    • C/I limits are relaxed to match Bluetooth® LE performance where justified:
      • Adjacent (2 MHz): Changed from -30 dB to -17 dB.
      • Adjacent (≥3 MHz): Changed from -40 dB to -27 dB.
      • Image frequency ±1 MHz: Changed from -20 dB to -15 dB.
  • For Bluetooth® Enhanced Data Rate (EDR):
    • A unified signal level of -67 dBm is also applied.
    • Limits are relaxed, maintaining the inherent performance difference (delta) between π/4-DQPSK and 8DPSK modulations:
      • For π/4-DQPSK:
        • Adjacent (2 MHz): -30 dB → -17 dB
        • Adjacent (≥3 MHz): -40 dB → -27 dB
        • Image frequency ±1 MHz: -20 dB → -15 dB
      • For 8DPSK (which requires higher SNR):
        • Adjacent (2 MHz): -25 dB → -12 dB (maintains a +5 dB delta vs. π/4-DQPSK)
        • Adjacent (≥3 MHz): -33 dB → -20 dB (maintains a +7 dB delta)
        • Image frequency ±1 MHz: -13 dB → -8 dB

7. Conclusion

Bluetooth® Core 6.3 introduces enhancements that improve ranging precision, interface scalability, and radio design efficiency. Advancements in Bluetooth® Channel Sounding reduce local oscillator error, lower processing and reporting overhead, and enable more accurate, PHY-aware distance measurements. Extensions to the Host Controller Interface support continued feature growth while maintaining backward compatibility, and harmonized RF requirements simplify dual-mode radio design and improve power efficiency. Together, these updates strengthen the technical foundation of Bluetooth technology and support continued innovation across a wide range of devices and use cases.

8. References

ItemLocation
Bluetooth® Core Specification v6.3https://www.bluetooth.com/specifications/specs/core-specification-6-3/
Bluetooth® Channel Sounding technical overview paperhttps://www.bluetooth.com/channel-sounding-tech-overview/