Bluetooth 6 是什麼？6.0～6.3 的差異、Channel Sounding 測距原理與普及現況

Bluetooth 6.0 對外發布的日期是2024 年 9 月 3 日；規格的版本紀錄則將2024 年 8 月 27 日列為 Bluetooth SIG 董事會的採納日期。這不是同一件事出現兩個日期，而是規格核准與對外公告屬於不同程序。

表格若超出畫面寬度，可左右捲動。

Bluetooth 6.x 的採納、發布日期與主要變化

版本	採納日	發布／公告日	主要變化
6.0	2024-08-27	2024-09-03	新增 Channel Sounding，改善裝置探索、音訊傳輸與封包間隔
6.1	2025-05-05	2025-05-06	將私有位址的更新時機隨機化
6.2	2025-11-03	2025-11-04	縮短連線間隔、強化測距抗攻擊能力，並支援透過 USB 傳輸 LE 音訊
6.3	2026-05-05	2026-05-06	改善測距相位補償、精度能力回報與 HCI 擴充

從 6.1 起，規格依每年兩次的發布週期持續更新，無須把這個週期當成更換手機的週期。規格改版是在增加設計者可以採用的功能與連線程序；已上市的裝置，不會在新版公告當天同時失去作用。

此外，商品標示的「Bluetooth 6」本身並不能說明哪些 6.x 新增功能已經啟用。以下先說明 6.0 建立的基礎，再逐一看後續版本改變了什麼。

6.0 的代表性新功能是 Channel Sounding（通道探測）。兩台已連線的 Bluetooth LE 裝置交換無線訊號，取得用來估算彼此距離的量測資料。在一次量測步驟中，先傳送訊號的一端稱為 Initiator，回應的一端稱為 Reflector。Reflector 不是像牆面或鏡子那樣的被動反射物，而是接收訊號後會主動回應的裝置。

這個訊號傳送順序，與要求啟動整個量測程序是兩回事。任一角色都可以要求啟動程序；Bluetooth LE 連線的 Central、Peripheral 角色，也不是分別固定對應測距的 Initiator、Reflector。

過去就能利用接收訊號強度 RSSI 判斷裝置是否接近。但訊號弱不一定代表距離遠，也可能是人體或家具遮擋、裝置朝向不同，或周圍反射造成。這就像只憑音量猜測說話者的距離，還得考慮對方本來說多大聲、中間有沒有牆。

Channel Sounding 不只看訊號強度，還利用以相位變化測距的 PBR，以及以往返時間測距的 RTT。這兩種方法可以單獨或搭配使用。規格定義相關訊號交換與量測結果的傳遞方式，但沒有把「如何從量測值算出最終距離」限定成單一演算法。

因此，不能說「只要是 6.0，誤差就一定在幾公分內」。即使支援同一功能，天線、校正、估算處理與使用環境仍會影響結果。規格支援與產品的實際測距表現，必須分別確認。

無線電波具有週期，相位表示波形目前位於週期中的哪個位置。即使傳播路徑相同，頻率改變時，波長與抵達時的相位也會改變。PBR（Phase-Based Ranging）利用不同頻率下量得的相位變化，取得與距離相關的線索。

但單一相位無法告訴我們「已經經過幾個完整週期」，就像只看時鐘指針，無法知道過了幾天。改變頻率、進行多次量測，是為了在處理這種週期性模糊的同時，找出與距離相關的變化。

每經過一個完整週期，相位就會重複

0

1

2

經過 0、1、2 個完整週期時，相位相同。

PBR 也利用頻率改變時，相位如何變化的資訊。距離估算會使用雙向量測與補償，包括處理振盪器偏差。

必須注意，量到的相位不只包含訊號傳播延遲。兩台裝置各有自己的振盪器，振盪器之間的偏差也會混入量測。實作需要雙向量測與補償，並不是「把單向收到的相位差直接換算成距離」這麼簡單。

表格若超出畫面寬度，可左右捲動。

不同測距方式取得的資訊，不應混為一談

方法	主要觀測資訊	解讀時的注意事項
RSSI 估算	接收訊號強度	除了距離，也會受到遮擋、朝向等因素影響
PBR	頻率改變時的相位變化	須處理相位重複、振盪器偏差與反射路徑
RTT	訊號往返所需的時間	須將回應等待與電路延遲，和訊號傳播時間分開

在室內，除了直接抵達的電波，接收端也會收到牆面等物體反射的電波，這種多條傳播路徑稱為多路徑（multipath）。改變頻率或天線路徑來量測有其價值，但不代表障礙物的影響會消失。看到「公分級」宣傳時，還要確認它是在什麼環境、距離與成功率下得到的數值。

RTT（Round-Trip Timing）利用訊號往返的時間估算距離。不過，從 A 傳送訊號到收到回應，還包含 B 準備回應所需的時間，必須將這段等待與電波在空間中的傳播時間分開。

RTT 將訊號往返的傳播時間與回應等待時間分開

A

B

A：此次訊號交換中先傳送的一端（Initiator）
B：回應的一端（Reflector）

綠色斜線：無線電波的傳播
赤褐色直線：B 的回應等待時間
時間由上往下；距離與時間皆未按比例繪製。

單程距離 ≈ 光速 ×（A 量得的經過時間 − B 的回應等待時間）÷ 2

以編輯部簡化的計算為例：若光速約為每秒 3 億公尺，單程 1 m 的傳播時間約為 3.33 ns，往返約為 6.67 ns。1 ns 是十億分之一秒。往返時間的估算只要相差 1 ns，距離估算就會相差約 15 cm。

這個例子不是預測產品誤差的公式，而是說明為何測距需要無線電路端的精密計時與補償。若從手機 App 呼叫傳送 API，再計時到收到回呼，作業系統的等待時間等因素也會算進去，並不是相同的量測。

這也說明 PBR 與 RTT 搭配使用的意義：不只依賴單一觀測值，而是結合不同線索，處理距離模糊或不合理的量測結果。但安全性仍不能只靠測距功能。以門鎖為例，「人就在附近」與「有權限開鎖」是必須分別確認的事情。

Channel Sounding 的介紹曾談到 10 公分級測距的潛力。例如 SIG 在 2023 年 11 月刊登的文章，討論的是規格制定完成前的表現，不能將其中的數值視為目前所有產品的保證。現行技術說明也指出，距離估算演算法並非由規格指定。規格名稱，不是對所有支援產品的精度保證。

「約 150 m」也需要看脈絡。這是在使用 1 MHz 頻率間隔的 PBR 中，用來說明相位重複所造成之距離模糊的數值；並不保證一般標籤能從 150 m 外被找到，更不代表在那個距離仍有公分級精度。實際可達距離還受到發射功率、接收靈敏度、天線與環境影響。

距離與位置也不相同。即使知道物品距離手機 2 m，仍無法單憑這項資訊判斷它在右邊、左邊或牆的另一側。方向估算與地圖上的位置顯示，需要其他觀測或處理。不能因為看見距離顯示示意，就認為每一款產品都會出現方向箭頭。

知道距離是 2 m，不代表知道該往哪個方向找

中心：手機
紫色圓點：對端裝置可能所在的位置範例

每個候選位置都距離中心 2 m；單靠距離無法判斷是哪一個。

要判斷方向或位置，還需要其他觀測資訊或處理。

UWB 也能用於近距離測距，但它是不同於 Bluetooth Channel Sounding 的無線技術；Android 測距 API 也將兩者分開處理。用途重疊不等於相容。即使 UWB 標籤能與 Bluetooth 6 手機連線，也不代表它會自動改用 Channel Sounding 測距。

比較裝置時，與其只問「UWB 還是藍牙」，不如一起確認支援的手機、App、可測距的對端、使用環境與續航力。本文不會把測試條件不同的廠商展示數字並列，據此判定精度高低。

6.0 不只新增測距。Bluetooth LE 裝置會透過 advertising 廣播封包，宣告自身存在或提供資訊。如果接收端對所有後續資訊都持續接收，也會花時間處理不需要的資料。Decision-based Advertising Filtering 讓接收端依據先收到的資訊，判斷是否繼續接收相關的額外封包。這裡的 advertising 是無線廣播機制，不是畫面上的商業廣告。

Monitoring Advertisers 則協助主機端掌握關注的裝置是否仍可被觀測到。即使省略重複通知有助於省電，也不能因此假設先前發現的裝置現在仍在附近。這項改善的價值，在於兼顧減少通知與掌握對端狀態。

音訊方面，將資料整理成傳輸單位的 ISOAL 層也有改善。新增的訊框處理模式（framing mode）稱為 Unsegmented Framed mode。它保留每個上層資料單位（SDU）的時間資訊，並讓一個 SDU 完整放入一個協定資料單位（PDU），不必再將它分成多個 PDU，因而減少分段造成的延遲。這不是替換音訊編解碼器本身，更不是只靠「6.0」就能決定音質。

此外，連線內的封包間隔，從原本固定的 150 µs，改為可由相互支援的裝置調整。這與後面介紹的6.2「連線間隔」縮短不同。可以把它想成縮小車廂之間的間距，與增加列車發車頻率的差別：先分清楚改變的是哪一段等待時間，就比較容易理解。

6.0 與 6.2 改變的是不同的間隔

6.0：一個封包結束，到下一個封包開始

綠色括號：封包間隔。從原本固定的 150 µs，改為可調整。

6.2：一次連線事件開始，到下一次事件開始

赤褐色括號：連線間隔。SCI 讓這個間隔的下限縮短。

6.1：不只改變位址，也改變更新時機

Bluetooth LE 可以使用可解析私有位址（Resolvable Private Address，RPA），避免持續廣播固定識別碼。6.1 的 Randomized RPA Updates 將更新時機隨機化，讓觀察者更難利用規律的更新時間進行追蹤。由控制器處理更新，也有省電方面的好處。

但這不表示所有追蹤都變得不可能。App 傳送的資訊、服務端持有的識別資訊，以及使用者授權的位置資訊，屬於不同層次。就像換了門牌上的姓名，若本人仍在別處自報身分，依然可能被辨識；不能把單一機制延伸成完全匿名的保證。

6.2：375 µs 是有條件的下限，不是總延遲

Shorter Connection Intervals（SCI）縮短 LE 連線中兩次通訊機會的間隔。相較於傳統的 7.5 ms 下限，SCI 必要支援範圍的下限是 1.25 ms，選用的延伸範圍則可達 375 µs。並非所有支援 SCI 的裝置，都必須支援 375 µs。

縮短兩次通訊機會之間的間隔

傳統連線間隔下限：7.5 ms
未使用 SCI 的連線基準

SCI 必要支援範圍的下限：1.25 ms
RCV：支援 SCI 時必須提供的範圍

SCI 選用範圍的下限：0.375 ms
ECV：須另行確認支援能力與使用條件

因為 7.5 ms ÷ 0.375 ms = 20，兩個間隔下限相差 20 倍；但這不代表遊戲操作快 20 倍，也不代表音訊延遲只有 375 µs。輸入取樣、作業系統處理、佇列、重傳、音訊編碼與播放，仍然需要時間。選擇較短間隔時，也必須權衡耗電與無線通訊壅塞。

6.2 還包含針對操控測距訊號振幅之攻擊的防護、主機與控制器透過 USB 連接時的 LE 等時音訊傳輸，以及無線測試改善。「縮短連線間隔」並不能概括整個版本。

6.3：改善測距補償與能力回報

6.3 的 Inline PCT Transfer 新增由 Reflector 端補償相位後回應的機制。在雙向量測與補償的基礎上，減少傳遞及處理量測結果的負擔。使用時需要兩端支援，並啟用這項功能。

此外，裝置可以依不同的 PHY（無線實體層模式），分別回報 RTT 精度相關能力；版本也擴充了 HCI 命令與事件的表示範圍。這些改良主要是讓實作能正確搭配，而不是能以一個醒目數字概括的性能提升。不能宣稱所有 6.3 裝置的精度都提升固定倍數。

官方資料能確認的是，Bluetooth 6 已進入消費型手機，也有手機 App 搭配開發套件測距的公開評估範例。但下列資料無法告訴我們市場上共有多少台 Bluetooth 6 裝置，或有多少人每天使用 Channel Sounding。本文不推估市場占有率，也不據此推估台灣、日本或其他地區的普及率。

表格若超出畫面寬度，可左右捲動。

官方資料中的採用案例，以及無法僅憑該資料推論的事項（基準日：2026 年 11 月 10 日）

案例	官方資料記載	不能單憑該資料斷定的事項
Apple iPhone 17	規格列出 Bluetooth 6；UWB 另列為獨立項目	支援所有 6.x 新增功能，或能與任意標籤使用 Channel Sounding
Google Pixel 10	規格列出 Bluetooth v6 與天線分集	支援所有測距 App 與對端裝置
Samsung Galaxy S26 英國型號 SM-S942BLBHEUB	所查核的官方規格列出 Bluetooth v5.4	其他型號或其他地區的規格，包括台灣販售版本
Android 16 以上的 Ranging API	可處理 BLE Channel Sounding、BLE RSSI、UWB 與 Wi-Fi RTT 的 API	所有 Android 16 手機都具備每一種測距方式的硬體
Nordic nRF54L15 DK	可用兩套開發套件試用 Initiator 與 Reflector 範例	可直接當成市售標籤使用，或保證相容於所有手機
Pixel 9/10 與 nRF Toolbox	Nordic 提供搭配 nRF54L15 DK 測距的步驟；OS、App 與 SDK 條件見下文	支援消費型尋物服務，或保證所有裝置與環境的精度

即使已有 iPhone 17、Pixel 10 等案例，也不能說新手機全部都採用 6；反過來，仍有 5.x 產品，也不代表 6 還沒商品化。多個世代會在同一市場並存。

Nordic 說明，nRF54L 系列從 nRF Connect SDK 3.0.1 起，可使用通過資格認證的主機與控制器來支援 Channel Sounding。這證明開發者已有可評估的基礎，但不等於消費者買到標籤後，就能把它加入既有的尋物服務。

更具體的例子，是 Nordic 公開的 Pixel 9/10 搭配 nRF54L15 DK 開發與評估流程：使用 Android 16 QPR2、nRF Toolbox 4.1.4 以上與 nRF Connect SDK 3.0.1 以上，將含有 android_ranging.conf 設定的 Reflector 範例建置並燒錄至 DK。手機連線並完成配對後，App 即可利用手機的測距能力顯示距離。這是廠商公布的評估範例，不是 NanToo 的實機測試。指南也談到 Android 17，但本文以正式版 QPR2 的組合為例，不將個別測試版的結果推廣到所有 OS 版本。

Android 雖然提供 API，官方指南仍要求在使用時確認裝置具備的能力，以及該能力當下是否可用。不能只看 OS 版本就假設功能一定存在。手機規格表與作業系統 API 文件回答的是不同問題，兩者不能互相取代。

使用情境也有限制。對使用 Android Ranging 模組的第三方 App 而言，背景測距僅限支援裝置上的 UWB；Channel Sounding 不允許在背景測距。在前景開啟 App 查看距離，與操作其他 App 時仍持續量測，是不同的情境。這是該 Android API 的限制，不代表所有廠商的系統功能或嵌入式裝置都適用相同規則。

從「支援 Bluetooth 6」到「能顯示距離」

手機端
相容的無線硬體

對端裝置
相容的無線硬體

兩端都支援 Channel Sounding

韌體與作業系統
啟用功能，並處理量測資料

App 與服務
與支援的對端測距，取得並顯示結果

使用時的條件
權限、設定、無線環境與前景使用等

使用 Android Ranging 模組的第三方 App，不得在背景執行 Channel Sounding 測距。硬體支援不等於能持續測距。

因此，編輯部的判斷是：Bluetooth 6 已用於實際產品，Channel Sounding 也能以特定組合進行評估；但一般尋物服務的支援條件，仍須個別確認。開發者能評估，不代表市售標籤就能立即在你平常使用的 App 中運作。

Bluetooth 6 的音質一定比較好？

比較音質時，要看編解碼器、設定檔（profile）、收發兩端的支援能力與實際連線設定。LE Audio、LC3、Auracast 都不是 Core 6.0 版本號的別名。相關原理可參考另一篇 Bluetooth LE Audio 與 Auracast 解說（日文）。

舊裝置就不能連線了？

新版本不會一律禁止與舊裝置通訊，但兩端仍需支援相容的無線模式、設定檔與功能。「能連線」不等於「能使用所有新功能」。舊耳機即使連上新手機，也不會自動具備測距能力或新的音訊系統。

靠軟體更新就能升級為 Bluetooth 6？

有些功能可以透過更新啟用，但若缺少必要的無線電路或時序控制硬體，軟體無法憑空補上所有功能。應確認廠商是否明確列出支援型號與功能，不要把晶片理論上能支援的能力，當成產品已承諾的更新計畫。

7.0 已經出現，是否該避開 6？

Bluetooth SIG 在 2026 年 11 月 4 日宣布採納 Core 7.0 的選用功能 HDT。不過，新規格公告不代表當天所有在售產品就會換代。挑選符合需求的產品，與追蹤未來規格，是可以分開處理的決策。本文不把 7.0 的功能混入 6.x，而是將其視為另一個版本的更新。

先選定一項想完成的用途，會比較容易判斷：聽音樂要看音訊功能；找鑰匙要看尋物服務與測距方式；低延遲輸入裝置則要看預定連線模式下的運作條件。想用單一 Bluetooth 版本號評估全部用途，容易做出錯誤判斷。

• 規格：除了 Bluetooth 版本，是否另外寫明需要的功能名稱？
• 對端：是否明確列出與你的手機、電腦或標籤搭配的條件？
• 軟體：作業系統、App、韌體的最低需求與提供時間為何？
• 性能：精度與延遲數值，是否附上測試環境與量測對象？
• 提供階段：能否區分已上市產品、開發套件與未來更新計畫？

開發者還要考慮量測失敗或結果不可靠時如何處理。例如門鎖是否只要一次估算距離偏短就允許解鎖？對於不確定性或可疑結果，又要如何應對？這些設計問題，不會因為採用規格就自動獲得解答。

Bluetooth 6.x 的價值不只是版本號增加，而是提供更細緻的方式來處理附近裝置之間的互動。6.0 加入測距等基礎，6.1 改善位址更新，6.2 改善連線間隔與安全性，6.3 則改進測距補償與能力回報。

規格是設計的共同語言，產品是規格的實作，使用體驗則取決於對端裝置與軟體如何一起運作。分開看這三個層次，「6 才開始普及，怎麼又有 7」就不矛盾。新規格持續發展時，前一代的實作與服務也仍在擴展；理解這段時間差，才能看清藍牙技術的演進。