Bluetooth 7.0 是什麼？與藍牙 6 的差異、HDT 7.5 Mbps 原理與支援現況

Bluetooth Core Specification 7.0 的文件日期是 2026 年 11 月 2 日。Bluetooth SIG 的功能概述於 11 月 3 日發布，宣布採納 HDT 的新聞稿則是 11 月 4 日。這三個日期分別對應規格文件、技術解說與新聞發布，不是同一事件出現互相矛盾的日期。

只記得「Bluetooth 7 要等到 2027 年」容易混淆這些層次。Core 規格已經確立，但要在此基礎上推出產品，仍需要應用規格與實作。SIG 預期在 2027 年展開的，是 HDT 首個主要應用：標準化的高品質無線音訊。這不是特定手機或耳機上市日期的保證。

閱讀這類消息時，應分別問「標準何時確立」與「我想連接的裝置組合能做什麼」。本文前半部說明規格，後半部整理有資料可查的實作進度，避免將未來預期混入目前可用的功能清單。

6.x 包含多次改版，6.0 與 6.3 的內容並不完全相同。6.0 的重點之一 Channel Sounding，是利用無線訊號估算裝置間距離的機制；7.0 的 HDT 主要改變的則是承載資料的能力。量測距離與傳送更多資料，解決的是不同問題。

這張表挑選各版的代表性變更，並非包含勘誤在內的完整清單。7.0 不是放棄 6.x 的測距功能、改成音訊專用規格，而是在既有架構上增加傳輸、控制與加密的選擇。與其把版本號當成「音質等級」，不如逐項確認自己需要的功能。

PBR、RTT 測距原理與 6.x 各版的細節，可參閱藍牙 6 測距原理與普及現況。接下來將以 7.0 新增的 HDT 為主，進一步說明。

實體層（PHY）定義如何將位元轉成無線訊號，以及接收端如何還原。傳統 LE 2M 的速率是 2 Mbps，與 HDT 的最高速率相比，7.5 ÷ 2 = 3.75 倍。這只是 PHY 速率之間的比較，不代表檔案傳輸一定快 3.75 倍，更不代表音質好上 3.75 倍。

HDT 是 Core 7.0 的選用功能。即使實作 HDT，基本必須支援的速率也是 HDT2、HDT3、HDT4；HDT6 與 HDT7.5 屬於額外的選用支援。此外還有傳送與接收的個別要求：支援 7.5 Mbps 接收，必須同時支援 6 Mbps 接收；支援 7.5 Mbps 傳送，則必須支援 6 Mbps 傳送與 7.5 Mbps 接收。單憑「支援 HDT」無法確定能否使用最高速率。

雙方共通的能力與無線通訊條件也會影響結果。選購時，不只要看規格欄的版本號，還要確認 HDT、所需的傳送與接收速率，以及另一端的裝置。開發時也不能預設只有一種固定速度，而應處理實作回報的能力資訊。

這次的 HDT 是擴充 2.4 GHz 頻段的 Bluetooth LE。整合式晶片的 Wi-Fi 支援 5 GHz 或 6 GHz，或另有朝更高頻段擴充的構想，都不應被當成 HDT 本身使用的頻段。

無線傳輸會將位元對應到接收端能區分的訊號狀態，每個這樣的傳送單位稱為符號（symbol）。若有 4 種可選狀態，就能表示 2 個位元；8 種可表示 3 個位元；16 種可表示 4 個位元。HDT 使用 π/4 QPSK、8PSK 與 16QAM 等調變方式。

但只增加狀態數還不夠。雜訊與傳播環境可能讓接收到的訊號偏離原本狀態，接收端仍必須判斷它原先代表什麼。因此，HDT 也使用前向錯誤更正（FEC），加入冗餘資訊來協助還原資料，而這些額外資訊同樣需要傳送。「每個符號 4 個位元」不等於「每個符號都有 4 個位元可供 App 使用」。

HDT 每秒傳送 200 萬個符號。將符號率乘上每個符號的位元數，再乘上有效碼率，即可算出各個 PHY 速率。碼率是資訊位元占編碼後位元總數的比例；碼率越高，用於冗餘資訊的比例就越低。

HDT7.5：2,000,000 × 4 × 15/16 = 7,500,000 bit/s = 7.5 Mbps。HDT2 則是 2,000,000 × 2 × 1/2 = 2,000,000 bit/s。即使同為 2 Mbps，LE 2M 與 HDT2 仍是不同的 PHY；速率數字相同，不代表無線實作相同。

因此，最高速率並不一定是最佳選擇。可承載的資訊量，必須與穩定辨識訊號狀態所需的條件一起評估。相較於只宣傳最高數字，說清楚各速率適用的條件，更有助於實際判斷。

通訊花費的時間不只用來傳送目標資料，還包含接收同步、標頭、回應與傳送間隔；出錯時也可能需要重傳。App 觀察到的實際傳輸速度，是已送達的資料量除以包含上述項目的總經過時間。

HDT 的改善也不只在調變。它能彙整資料，並支援區塊層級的確認與重傳，讓大型資料傳輸中部分內容遺失時，更容易處理失敗的區塊。不過，各產品使用的封包格式與額外功能不一定相同。

封包較短時，HDT 甚至可能比 LE 2M 更慢。Nordic 的技術解說指出，同步與控制等程序會占用固定時間。當承載的資料很少，這些時間占比就會變大，即使提高無線最高速率，整體傳輸仍可能更不利。較長的封包則能讓更多資料分攤這項成本。HDT 從多大的資料量開始有優勢，取決於實作與無線條件；不能套用單一固定門檻，而應以實際傳送的資料量與頻率來比較。

例如採十進位單位，1 MB 等於 8,000,000 bit。只計算以 7.5 Mbps 傳送這些位元，理想結果約為 1.07 秒。但若將它寫成產品實際的檔案傳輸時間，就會誤導讀者，因為控制資訊、通訊條件與主機端處理都會增加成本。比較時必須交代量測條件，也要分清楚檔案大小使用的是 MB 還是 MiB。

電池續航力也不能直接推論。同樣的資料若更快傳完，無線硬體就有更多休息時間；但維持較高速率所需的處理，以及整台裝置的耗電，也必須納入考量。這是節能的可能性，不是所有 HDT 產品都能按固定比例延長續航的保證。

音訊資料量能讓頻寬問題更具體。未壓縮 PCM 的資料率等於取樣率 × 位元深度 × 聲道數，立體聲以 2 個聲道計算。

4.608 小於 7.5，不代表所有產品都能做到 96 kHz / 24 bit 無損播放。將音訊資料率從最高 PHY 速率中扣除，並不能得出所需的餘裕或互通條件。若採無損壓縮，資料率還會隨內容改變。

HDT 負責傳送資料，編解碼器負責音訊的表示方式。更高的傳輸能力能增加音訊設計的選擇，但不代表可以省略雙方相容的音訊格式、Profile 與實作。HDT 不會讓編解碼器變得不必要，也不會自動提升既有錄音的音質。

這項區別也影響換機判斷。只買一端標示 Bluetooth 7.0 的裝置，若另一端或軟體缺少必要支援，就無法啟用 HDT。反過來說，現有裝置若已能穩定提供所需的音訊模式，就沒有必要只為新版本號換機，因為音質並非單由無線規格版本決定。

7.0 的另一個方向，是在維持連線的同時適應需求變化。LE Isochronous Parameter Update（IPU）可調整 Connected Isochronous Stream（CIS）的傳輸設定；CIS 是以連線為基礎、配合時間要求傳遞資料的串流。裝置不必重建串流，而是協調切換到事先準備好的設定。這可能有助於因應音訊需求或無線環境變化，但不保證每次切換都不會產生可聽見的中斷或延遲。

Encryption Key Schedule（EKS）是衍生、分離與更新金鑰的架構。Transient Application Key（TAK）則讓上層應用程式處理身分驗證與金鑰建立，再用該金鑰加密鏈路。對短暫的資料交換而言，這提供了不依賴傳統配對或長期儲存金鑰的選擇。不依賴配對，不代表不必確認對方身分。

Encryption Production Debugging（EPD）也新增了開發與互通性測試時分析加密通訊的支援。這些功能改善的是控制、安全與驗證，不能全部歸類為提升音質的功能。使用時仍需要適當的實作與評估。

目前的第一手資料可確認幾個進展：規格已採納、晶片廠商已說明 HDT 支援、已有實體晶片展示，以及作業系統 API。但把這些資訊相加，仍無法證明現在能買到的手機與耳機已能透過 HDT 音訊互通。

Qualcomm 的例子說明，不能只看標題。HDT 功能名稱、目前的規格版本欄位與草案註腳同時存在；本文不會將它改寫為「Bluetooth 7.0 產品已上市」。廠商日後明確說明符合最終規格或列出搭載產品時，仍需另行確認。

Nordic 的發布證明技術已從概念走到實體晶片階段。不過，這則消息發布於 10 月，早於規格採納。文中「預計今年稍後發布規格」是當時的預期，現在的狀態必須搭配 SIG 在 11 月發布的資料閱讀。

在 Android 上，BluetoothAdapter.isLeHighDataThroughputPhySupported() 會回傳支援狀態，而 BluetoothDevice.PHY_LE_HDT 等常數可用來表示 HDT PHY。API 的出現顯示開發平台正在準備，但不會讓缺少必要硬體的裝置憑空增加無線能力。軟體也必須處理不支援與狀態不明等情況。

在本次查閱的官方資料範圍內，尚未確認有明確支援 HDT 使用的市售智慧型手機與耳機組合，也未確認市場普及率。這不是調查市場上所有產品後，證明這類組合不存在；也不會只因找不到資料，就斷言所有 iOS 或 Windows 裝置都不支援。要進一步補充，仍需確認各地區、各型號的正式規格。

是否該等 Bluetooth 7.0，取決於目前想解決的問題。要量測遺失物品的距離，Channel Sounding 的實作與 App 支援比 HDT 最高速率更重要。要聽音樂，則應考慮手機與耳機共通的音訊模式、連線穩定性與配戴舒適度。對需要傳送大量感測器紀錄或韌體的開發者而言，能量測 HDT 實際傳輸速度與耗電的評估環境更有價值。

如果是感測器讀值等少量資料、頻繁傳送的用途，LE 1M 與 LE 2M 仍應保留在比較範圍。一次傳送大型紀錄檔，和反覆傳送短通知，是不同負載；除了速度，也應量測等待時間與耗電，再決定使用方式。

• 功能：是否支援 HDT，以及所需的傳送與接收速率？
• 可用階段：是預告、原型展示、SDK 支援，還是產品已啟用的功能？
• 對端與軟體：兩端裝置、作業系統、韌體及音訊實作，是否都支援預期用途？
• 量測條件：數字是最高 PHY 速率，還是實際傳輸速度？是否說明距離、干擾、重傳與功耗條件？

能否透過軟體更新支援，也不能只看版本號。缺少必要的無線電路，就無法新增 HDT；即使硬體具備能力，仍需要廠商實作、啟用與驗證。沒有個別產品的根據，既不能說全部都必須換機，也不能說全部都能靠更新支援。

總結來說，Bluetooth 7.0 增加了 Bluetooth LE 可承載的資料量，也擴充通訊過程中的調整能力與金鑰管理。標準確立是重要的起點，但當兩端裝置與軟體都能協同運作時，才會轉化為使用者實際能用的功能。在 Bluetooth 6 邁向 7 的過渡期，除了期待新版本，更值得確認功能、使用條件與實作成熟度。