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）定義如何將位元（bit）轉成無線訊號，以及接收端如何還原。傳統 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 的過渡期，除了期待新版本，更值得確認功能、使用條件與技術成熟度。