What Is Bluetooth HDT?
Bluetooth High Data Throughput (HDT) is an upcoming Bluetooth LE feature that increases the maximum PHY data rate from today’s 2 Mbps to as much as 7.5 Mbps. It represents one of the largest changes to the Bluetooth LE radio since Bluetooth 5 introduced the LE 2M and LE Coded PHYs.
The change isn’t simply a matter of making the existing radio run faster. HDT introduces new modulation methods, forward error correction, much larger packets, block-based transmission, adaptive data rates, and changes to encryption. Together, these changes make Bluetooth LE much better suited for applications like large file transfers, firmware updates, high-rate sensors, advanced wearables, and future high-quality audio.
| Feature | BLE 1M | BLE 2M | Bluetooth HDT |
|---|---|---|---|
| Maximum PHY rate | 1 Mbps | 2 Mbps | 7.5 Mbps |
| Symbol rate | 1 Msym/s | 2 Msym/s | 2 Msym/s |
| Modulation | GFSK | GFSK | QPSK/QAM variants |
| FEC | No | No | Yes |
| Adaptive rates | PHY switching | PHY switching | Multiple HDT rates |
| Large blocks | No | No | Yes |
| Target use | General BLE | Faster BLE | High-throughput BLE |
There’s an important detail, though. Bluetooth HDT isn’t part of the currently adopted Bluetooth Core Specification yet. The Bluetooth SIG has published a public draft based on Bluetooth Core 6.2, and adoption is expected in a future Core Specification release. That means the details discussed here describe the current HDT proposal and could still change before final adoption.
Here’s how it works and why it’s a much bigger change than simply adding a “faster PHY.”
Why Bluetooth LE Needs More Speed
Bluetooth LE originally launched with a 1 Mbps PHY. Bluetooth 5.0 later introduced the LE 2M PHY, doubling the physical bit rate to 2 Mbps while retaining the basic GFSK modulation approach used by Bluetooth LE.
The 2M PHY is considerably faster than the original PHY, but Bluetooth applications have become even more demanding.
A smartwatch might need to synchronize large chunks of stored sensor data. A device receiving an over-the-air firmware update might need to download several megabytes. Industrial sensors can produce continuous streams of measurements, while cameras and advanced sensing systems can produce vastly more data than traditional temperature or motion sensors.
Audio is another major driver. LE Audio works well within today’s Bluetooth LE bandwidth because the LC3 codec is designed to provide good audio quality at relatively low bit rates. But one complaint that has dogged Bluetooth since the beginning is the audio quality. The current 2Mbps PHY just can’t meet all the demands of lossless audio and high bit-rate codecs. Higher-quality audio, multiple simultaneous streams, and potential lossless audio applications simply need a faster radio.
The problem isn’t necessarily that 2 Mbps is slow. It’s that the 2 Mbps PHY rate isn’t the same thing as 2 Mbps of application throughput.
Bluetooth packets contain headers, checksums, link-layer information, encryption information, acknowledgements, and other overhead. Devices also need gaps between transmissions and may lose packets that have to be retransmitted. The application therefore receives considerably less useful throughput than the raw PHY rate suggests. HDT gives Bluetooth much more room to work with.
The Bluetooth SIG currently describes a maximum HDT bit rate of 7.5 Mbps, almost 4x the maximum 2 Mbps rate available with conventional Bluetooth LE.
Bluetooth HDT Isn’t Just a Faster 2M PHY
It’s tempting to think of the BLE progression as 1M PHY → 2M PHY → 7.5M PHY
That’s an easy way to visualize the improvement, but in reality HDT is much more complicated.
The existing LE 1M and LE 2M PHYs use Gaussian Frequency Shift Keying, or GFSK. The radio represents information through changes in frequency. It’s relatively simple to generate and receive, which is one reason Bluetooth LE radios can be small and power efficient.
HDT introduces a considerably more advanced physical layer that leverages techniques often used in Cellular and Wi-Fi.
Instead of relying entirely on the modulation approach used by today’s Bluetooth LE PHYs, HDT can use higher-order modulation techniques, including forms of Quadrature Phase Shift Keying (QPSK) and Quadrature Amplitude Modulation (QAM).
These modulation schemes allow the radio to encode more information into each transmitted symbol. That’s the fundamental trick behind HDT. Instead of just simply transmitting symbols dramatically faster, Bluetooth can put more bits into the symbols it’s already transmitting.
The HDT Data Rates
The current Bluetooth HDT proposal defines several bit rates:
| HDT Mode | Bit Rate |
|---|---|
| HDT | 2 Mbps |
| HDT | 3 Mbps |
| HDT | 4 Mbps |
| HDT | 6 Mbps |
| HDT | 7.5 Mbps |
All of these modes use a 2 megasymbol-per-second signaling rate. And it’s important to realize that radios like Nordic’s nRF54L15 have a 4Mbps Data Rate, although whether that meets the BLE specification is yet to be seen.
This distinction between symbols and bits is important.
A symbol is a radio state transmitted over the air. With simple modulation, one symbol might represent one bit. With higher-order modulation, one symbol can represent multiple bits.
For example, QPSK can represent four possible symbol states. Four states allow each symbol to carry two bits of information.
QAM can go further by encoding information using combinations of amplitude and phase.
This lets HDT increase the bit rate without increasing the symbol rate by the same amount.
It’s a common technique in higher-performance wireless systems. Wi-Fi, cellular networks, cable modems, and many other communication systems use increasingly complex modulation to carry more bits per symbol. Bluetooth LE is now moving in that direction as well.
Why HDT Uses Multiple Data Rates
If 7.5 Mbps is available, why wouldn’t Bluetooth simply use 7.5 Mbps all the time?
The quick answer is because higher-order modulation comes with a price. As more bits are packed into each symbol, the receiver has to distinguish between radio states that are increasingly close together. Noise, interference, distortion, frequency errors, phase errors, and poor signal strength make that harder.
This means higher data rates force shorter range
Imagine trying to distinguish between two points on a graph. If the points are far apart, a little measurement error doesn’t matter much. But If there are dozens of points packed closely together, the same amount of error can cause the receiver to choose the wrong one. That’s one reason HDT includes multiple bit rates.
A device with an excellent RF link might run at 7.5 Mbps. As signal quality gets worse, the devices can move to 6 Mbps, 4 Mbps, 3 Mbps, or another supported mode. Not every application needs 7.5Mbps, and much of the work of products designers will be to balance all these factors in their product.
The goal isn’t simply to run at the highest possible PHY rate. It’s to achieve the highest reliable throughput for the current radio conditions and your application.
HDT Can Change Data Rates Packet by Packet
One of the more interesting parts of HDT is how quickly the data rate can change.
An HDT packet identifies the data rate being used in its header. This allows devices to switch rates between packets rather than treating the PHY selection as a long-term configuration.
Suppose two devices are sitting next to each other. The connection might have enough signal-to-noise ratio to reliably operate at 7.5 Mbps. Now someone walks between them, the device moves farther away, or a nearby Wi-Fi transmitter starts using the same part of the 2.4 GHz spectrum. The error rate could suddenly increase.
Instead of continuing to transmit at 7.5 Mbps and suffering repeated packet failures, the transmitter can move to a more robust HDT rate. When conditions improve, it can increase the rate again.
The current proposal also includes an optional link-quality feedback that can provide the transmitter with information about conditions at the receiver.
This makes HDT rate selection somewhat similar in concept to rate adaptation used by other wireless technologies. The fastest theoretical rate isn’t always the fastest way to move data if packets constantly have to be retransmitted.
HDT Introduces Forward Error Correction
Higher-order modulation creates another problem. Increasing the number of bits carried by each symbol generally makes the radio more sensitive to errors.
Bluetooth HDT addresses this partly through Forward Error Correction, or FEC.
FEC adds redundant information to transmitted data. The receiver can use that redundancy to recover some corrupted bits without asking the transmitter to send the data again.
HDT uses physical-layer FEC across its data rates, with the current design based on convolutional coding. There is obviously a cost. FEC consumes some of the transmitted bits with redundant information rather than application data. But retransmissions are expensive and FEC reduces this expense.
If a large packet contains one unrecoverable error, retransmitting that data consumes additional airtime and energy. Correcting a small number of errors directly at the receiver gives better average throughput than simply maximizing the number of uncoded bits sent over the air.
FEC becomes especially valuable as Bluetooth moves toward higher-order modulation where the radio has less noise margin.
HDT Changes Bluetooth Packet Structure
Increasing the modulation rate alone wouldn’t solve every throughput problem. Bluetooth also needs to move data efficiently once the radio becomes much faster.
HDT introduces a new packet structure designed around larger transfers. The Bluetooth SIG says HDT packets can scale to payloads of more than 8,000 bytes in the largest configurations. That’s dramatically larger than the packets developers are accustomed to working with on conventional Bluetooth LE links, and the standard Bluetooth packet format.
Sending huge packets creates another problem, however.
Imagine transmitting an 8 KB packet and discovering that interference corrupted a tiny section near the end. Retransmitting the entire 8 KB would waste a considerable amount of airtime.
HDT addresses this with a block-based transmission system. Instead of treating the complete large payload as one indivisible piece of data, HDT can divide it into smaller blocks. Each block has its own error-checking information. If interference damages one block, the receiver doesn’t necessarily need the entire large packet again. The affected portion can be handled separately. This becomes increasingly important as packet sizes grow.
Selective Acknowledgements Make Large Transfers More Efficient
The block architecture also changes the way acknowledgements can work.
Traditional packet communication often follows a simple model: send a packet, determine whether it arrived successfully, and retransmit it if it didn’t. That’s manageable when packets are relatively small.
With HDT, the radio can work with individual blocks inside a much larger transmission. The receiver can selectively acknowledge blocks, allowing the sender to identify which portions arrived successfully. This gives Bluetooth much finer control over retransmissions.
The system can also interleave traffic. A device doesn’t necessarily have to transmit every block belonging to one large payload before anything else can use the connection. That matters because high throughput and low latency aren’t always the same thing.
Imagine a device transferring a large file while also carrying latency-sensitive control data. A huge uninterrupted transfer could otherwise delay the control traffic. Block-based transmission gives the link more flexibility to balance those requirements.
7.5 Mbps Doesn’t Mean 7.5 Mbps of Application Data
This is an important distinction when discussing HDT.
The 7.5 Mbps figure is a PHY bit rate, not a promise that an application will receive exactly 7.5 megabits of usable payload every second. HDT still has packet headers, error correction, integrity protection, timing requirements, acknowledgements, retransmissions, and link-layer operations. Application protocols like ATT, GATT, L2CAP, or future transports can introduce additional overhead.
Real throughput will depend on several factors, including packet configuration, connection scheduling, encryption, radio conditions, controller implementation, host stack behavior, and the application protocol being used.
The Bluetooth SIG still expects a major improvement in real-world throughput. It has cited early member demonstrations where a multi-megabyte transfer taking roughly 16 seconds using existing Bluetooth LE could take around four seconds using HDT. That shouldn’t be interpreted as a universal four-times improvement for every Bluetooth application, but it gives a useful idea of the scale of the change.
HDT Could Actually Reduce Energy Consumption
Higher radio speeds sound like they should require more power, and in many ways they do. Instantaneous radio power may indeed change depending on the implementation. A more complicated receiver capable of coherent detection and higher-order modulation will generally require more RF and digital signal-processing hardware than a basic GFSK receiver.
But instantaneous current isn’t the only measurement that matters in a battery-powered wireless device. The other important measurement is energy per transferred bit.
The higher-performance radio might consume more current while active, but it can spend far less time active.
FEC and block retransmission can help as well. Correcting errors without retransmitting large amounts of data reduces wasted radio airtime.
The actual energy savings will depend heavily on the Bluetooth controller implementation and RF conditions, so HDT shouldn’t automatically be assumed to use less energy in every application. For burst-oriented applications like firmware updates and synchronization, however, finishing transmissions much faster can provide a major power advantage.
HDT Requires a More Advanced Radio
All these features sound great, but there’s a hardware consequence to all of this.
You shouldn’t expect existing Bluetooth LE chips to gain full HDT support through a simple firmware update. A radio designed around LE 1M and LE 2M GFSK operation doesn’t automatically contain the analog and digital hardware required to receive higher-order modulation.
QAM is particularly demanding because information can be encoded in both phase and amplitude. Receiver impairments that weren’t especially important for GFSK can become much more significant. Radio designers need to consider issues like phase noise, I/Q imbalance, error vector magnitude, oscillator performance, amplifier linearity, ADC performance, and baseband processing.
The move from conventional Bluetooth LE to HDT is therefore more than a protocol-stack change. It’s a large radio architecture change.
The transition to support Bluetooth 5.0 and the 2Mbps PHY took a couple of years, and HDT is probably going to take longer. And radios are not likely to support all data rate combinations, so taking advantage of the radio will depend.
HDT and Bluetooth Range
Higher data rates also don’t mean Bluetooth suddenly gets more range. In general, the highest HDT modes will work best when radio conditions are good. At longer distances or in noisy environments, devices may need to move to a more robust data rate.
This is why adaptive rate selection is so important, since range depends on the data rate.
Bluetooth already follows a similar overall idea with its existing PHY options. LE Coded PHY trades throughput for much greater link robustness, while LE 2M favors throughput when radio conditions allow it. HDT adds several more points along that performance curve.
A future Bluetooth controller could therefore have a very wide range of operating modes available, from low-rate coded communication optimized for reliability through multi-megabit HDT communication optimized for throughput.
The right PHY depends on what the application is trying to accomplish.
HDT Also Changes Bluetooth Security
Moving dramatically more data through Bluetooth has also led the SIG to revisit parts of the link’s security architecture.
Traditional encrypted Bluetooth LE packets use a 32-bit Message Integrity Check, or MIC, to authenticate encrypted packet data.
HDT introduces support for larger 64-bit and 128-bit MICs.
The draft also introduces an Encryption Key Schedule designed to manage keys and security parameters as devices transition between conventional GFSK and HDT operation. Because large amounts of data are being exchanged, periodic key changing can be important to ensure the data stays secure.
Another interesting addition is support for Opportunistic Encryption. This can allow encryption to be established even when devices haven’t previously paired or established a long-term key.
The HDT security work also includes mechanisms for stronger key separation and support for ephemeral ECDH exchanges that can provide forward secrecy.
These changes make sense when considering where Bluetooth is heading. If the technology begins carrying much larger amounts of data, higher-quality media, and more complex application traffic, its security architecture has to scale with it.
HDT and LE Audio
Audio is probably the biggest and most visible targets for for HDT.
Today’s LE Audio uses the LC3 codec to deliver good audio quality efficiently over Bluetooth LE. That efficiency is important because current Bluetooth LE bandwidth is limited. But if you ask anyone who runs LC3, you’ll know that high rate quality isn’t that good. And that’s a problem because Bluetooth’s main use case, the one that has been used for years is Audio.
HDT changes the bandwidth budget considerably. A 7.5 Mbps radio is much faster than even the 3Mbps of Bluetooth Classic EDR and opens the possibility of substantially higher audio bit rates, additional simultaneous streams, higher-resolution formats, and potentially lossless Bluetooth audio. These are the things consumers have been asking for years from Bluetooth – a real cable replacement.
That doesn’t mean HDT itself defines a new lossless audio codec. The PHY provides bandwidth. Audio profiles, codecs, controllers, operating systems, and devices still need specifications and implementations that know how to use it, and there’s plenty of existing codecs from Qualcomm’s AptX family to AAC, LDAC and others.
The Bluetooth SIG has separately identified high-resolution and lossless audio as areas of future development. HDT provides much more of the raw wireless capacity required to make those features practical over Bluetooth LE.
Firmware Updates Could Be One of the Biggest Winners
One of the less glamorous but potentially more useful applications for HDT is firmware updating. If you’ve worked with any kind of BLE sensor or product you know they need firmware upgrades, and these can take up to a minute. Firmware Firmware images keep getting larger as BLE makes it way to more and more complex applications.
That affects more than user convenience. During an update, the device may need to keep its radio, processor, flash subsystem, and other hardware active.
Reducing an update from tens of seconds to a fraction of that time improves the user experience and potentially reduces the energy required for the update. The same applies to log extraction, sensor synchronization, map transfers, configuration databases, and other burst transfers.
High-Rate Sensors Become Much More Practical
Bluetooth LE has traditionally been excellent for sensors that produce relatively small amounts of information. Temperature, humidity, heart rate, battery voltage, switch states, and similar measurements require very little bandwidth.
Modern sensors can be completely different. High-rate IMUs, vibration sensors, industrial monitoring equipment, medical instrumentation, radar sensors, and other systems can generate hundreds of thousands or millions of samples.
Developers currently have to reduce sampling rates, compress data, buffer measurements for later transfer, or use another wireless technology. HDT gives Bluetooth significantly more headroom.
A device might still process sensor data locally to reduce bandwidth, but the radio is less likely to be the primary bottleneck.
This could make Bluetooth a more realistic interface for devices that previously needed Wi-Fi or a wired USB connection whenever large datasets had to be retrieved.
HDT Doesn’t Replace Wi-Fi
A 7.5 Mbps Bluetooth PHY sounds fast, but HDT shouldn’t be viewed as a replacement for Wi-Fi.
Modern Wi-Fi offers vastly greater peak throughput, and that use case won’t change.
But Bluetooth has a huge use case as it’s deeply integrated into phones, tablets, computers, wearables, automotive systems, and embedded products. It provides discovery, pairing, security, low-power operation, standardized profiles, and a mature device ecosystem.
For an embedded device that needs to move a large amount of data quickly, this can actually be a power advantage. The radio may consume more power while transmitting at the higher data rate, but it can finish the transfer sooner and return to a low-power state. What matters for a battery-powered product isn’t just instantaneous current consumption, but the total energy required to move a given amount of data.
This is one of the reasons Bluetooth HDT could be particularly interesting for embedded systems. BLE already has a mature low-power connection model, and adding significantly more bandwidth could make it practical for applications that currently have to add Wi-Fi or another radio just to handle occasional large transfers.
HDT Could Change Bluetooth Gateways
Gateways are another area where the additional bandwidth could matter.
A typical BLE gateway usually communicates with dozens or even hundreds of sensors. Individual sensors may generate very little traffic, but aggregate traffic can grow quickly. Gateways have to carefully manage scanning, connections, connection intervals, controller buffers, and scheduling.
HDT doesn’t eliminate those problems. A Bluetooth controller still has finite radio time and finite resources. But faster transfers can change the scheduling and give the radio a lot more time to service those devices.
Smartphones Will Be Critical to HDT Adoption
The technical specification for HDT is only half of the story. Bluetooth features become truly useful when they’re supported by the devices people already own, especially smartphones. The reality is that LE features tend to gain traction when Apple and Google adopt them. The delay in Apple adopting LE Audio for example has really slowed it down.
LE 2M, LE Coded PHY, Direction Finding, LE Audio, Channel Sounding, and other Bluetooth capabilities haven’t appeared everywhere at once. Controller support, operating-system support, APIs, qualification, and application support all take time.
HDT will likely follow a similar path. The first Bluetooth controllers supporting the necessary radio capabilities will appear, followed by development kits and early products. Smartphone support will then be one of the biggest factors determining how quickly HDT becomes useful to mainstream embedded developers.
This means engineers shouldn’t design a product around HDT simply because the specification exists. Host device support has to be part of the product requirements. And like every Bluetooth specification, especially for such a large one, issues may appear that require an errata to fix.
Backward Compatibility Still Matters
Bluetooth’s enormous installed base is one of its biggest advantages. Any major new feature therefore has to exist alongside older Bluetooth devices.
An HDT-capable peripheral will still need to communicate with phones and computers that only support existing LE PHYs. In those cases, the connection can operate using a mutually supported PHY instead. That means manufacturers can add HDT without making their devices useful only with the newest hardware.
The user experience might simply be different. Connect an HDT-capable product to an older phone and a firmware update might take considerably longer. Connect the same product to an HDT-capable phone and the transfer could complete much faster.
Applications will need to account for this rather than assuming the fastest mode is always available.
HDT Makes the Bluetooth Controller More Important
Higher data rates can expose bottlenecks elsewhere in the system.
Imagine a Bluetooth controller capable of moving several megabits per second over the air while communicating with the application processor through a relatively slow UART.
The radio isn’t the bottleneck anymore. The host interface is.
The same problem can appear with SPI transports, controller buffers, DMA architecture, memory bandwidth, interrupt handling, and the Bluetooth host stack itself.
Integrated Bluetooth SoCs may have an advantage because the host and controller can exchange information through shared memory or high-speed internal interfaces. Designs using an external Bluetooth controller will need to make sure the HCI transport can sustain the required rate. But CPUs will still need to be able to push that throughput. It’s part of the reason why Nordic and others have moved to even faster CPUs, from 64Mhz to 128MHz with more cores.
Firmware architecture matters too.
An application that copies every packet several times between buffers can consume significant CPU time at multi-megabit data rates. Zero-copy or reduced-copy architectures, DMA, larger buffers, and efficient memory management become increasingly valuable as throughput rises.
In other words, HDT isn’t only an RF feature. It can affect the architecture of the entire embedded system.
Bluetooth Classic is Getting Replaced
Despite being over 20 years old, Bluetooth Classic is still around. It still dominates Audio for the simple reason that it can support high data rates up to 3Mbps which are needed for higher bit rates.
But we’ve known for a long time that Bluetooth Classic is slowly dying. It’s still shipping, but BLE is eating up Bluetooth Classic use cases. LE Audio hasn’t managed to replace it yet because Apple’s didn’t include LE Audio support. But that’s slowly changing, and it’s likely Apple was looking for higher data rates before starting to move away from Bluetooth Classic.
High Data Throughput adds what is essentially the final nail in the coffin for Bluetooth Classic. HDT can provide substantially more throughput than Bluetooth Classic’s EDR modes, removing one of the biggest remaining technical reasons to use the older BR/EDR transport.
HDT takes advantage of a lot of improvements in wireless communications developed in the last 20 or so years since it was adopted for Wi-Fi and Cellular. This means a much better radio performance that BT Classic won’t be able to match. This is also why Bluetooth Classic didn’t get an upgrade – it just didn’t make sense when the basic Radio PHY is limited.
Summary
BLE has moved from being a low cost low power technology into a much broader communication protocol. The Bluetooth SIG is working hard to address the throughput gap that has been affecting Bluetooth LE and preventing it from new applications and from finally getting Bluetooth Audio running at the bit rates people wanted.
Bluetooth High Data Throughput (HDT) is set to give Bluetooth LE one of its biggest speed upgrades yet, increasing the maximum PHY data rate from today’s 2 Mbps to up to 7.5 Mbps. HDT is aimed at applications that need to move much more data while keeping the low-power and short-range advantages that have made BLE popular in embedded devices.
HDT won’t replace existing BLE PHYs, and 7.5 Mbps shouldn’t be confused with actual application throughput. Devices will still use existing Bluetooth modes when they make more sense for range, compatibility, or power consumption. Instead, HDT gives future Bluetooth devices another option when they need to move a lot of data quickly, potentially closing an important gap between traditional BLE and higher-bandwidth technologies such as Wi-Fi.
