|
|
|
16-4 基頻協定
『基頻協定』（Baseband protocol）是整個 Bluetooth 技術的核心，它的規範顯然複雜了許多。基頻協定是位於無線電協定與 L2CAP 或 LMP 協定之間（如圖 16-1 所示），負責整個 Bluetooth 網路的運作，但也大多著重於 Piconet 網路內的通訊處理。基頻協定在規格書裡佔了很大的份量，也包含了許多技術規範，以下我們以重點方式來介紹相關規格，以及其運作方式。 16-4-1 裝置位址型態 在敘述基頻規格之前，我們先認識一下如何表示某一個 Bluetooth 裝置的位址，有下列四種型態。 (A) BD_ADDR 位址 每一個 Bluetooth 裝置都有一個『藍芽裝置位址』（Bluetooth Device Address, BD_ADDR），這是工廠生產 Bluetooth 裝置時，便將它燒錄在裝置裡面，如同目前的 Ethernet 網路卡一樣，廠商在生產時便將 Ethernet Address 預先設定好了，以後也無法更改。但 BD_ADDR 與 Ethernet 位址有很大的不同點，Ethernet 位址只是一個主機（或網路卡）的識別值，沒有其它用途；然而 BD_ADDR 的內容還有許多用途。全世界所有 Bluetooth 裝置的 BD_ADDR都是由 Bluetooth SIG 協會負責分配與管理，製造商需要 BD_ADDR 時都必須向 Bluetooth SIG 協會申請。 每一裝置的 BD_ADDR 位址，在 Bluetooth 網路（Piconet 或 Scatternet）上是唯一的識別值，並且可說是 Bluetooth 技術的運算核心。幾乎所有負責 Bluetooth 系統正常運作的參數都是由 BD_ADDR 計算出來的，譬如：跳頻順序（Hopping Sequence）、通道存取碼（Channel Access Code, CAC）與加密鑰匙（Encryption Key）皆是。 圖 16-5 為 BD_ADDR 的結構圖，其中包含了24 個位元的『較低位址部份』（Lower Address Part, LAP）、8 個位元的『較高位址部份』（Upper Address Part, UAP）、以及 16 個位元的『未定義位址部份』（Non-significant Address Part, NAP）。其中 UAP 是 Master 裝置用來計算跳頻順序使用，也就是說，在一個 Piconet 網路內的跳頻順序是由該網路 Master 裝置的 UAP 計算得來。 LAP 的用法就較為特別，每一個 Piconet 網路都有個唯一的CAC（Channel Access Code）識別碼，就是由 Master 裝置的 LAP 計算出來的。LAP 的另一應用是，當 Slave 回應 Master 的翻頁（Paging）呼叫時，所使用的 DAC（Device Access Code）識別碼，也是利用 Slave 裝置的 LAP 計算得的。另外，NAP 並沒有定義使用方法（只當識別使用）。
圖 16-5 BD_ADDR 位址結構 (B) AM_ADDR 位址 在 Piconet 網路下，當 Slave 裝置為『活動狀態』（Active State）時，Master 將會分配給每個 Active 裝置一個『活動組員位址』（Active Member Address, AM_ADDR），Master 就是經由這個位址來辨識各個裝置。一般 Master 和 Slave 之間的通訊，是由 AM_ADDR 來識別各個裝置，亦即當裝置（Master 或 Slave）收到封包時，由 AM_ADDR 位址來判斷該封包是否傳送給自己。 簡單的說，AM_ADDR 位址是 Piconet 網路上可以通訊之活動成員的識別值，之間通訊便利用這個位址來識別。AM_ADDR 位址是由 3 個位元所組成，因此在同一個 Piconet 網路內最多可以存在 8 個活動裝置，而 Master 裝置的 AM_ADDR 位址固定為 000。 (C) PM_ADDR 位址 當 Slave 裝置處於『停放狀態』（Park State）時，Master 都會分配一個『停放組員位址』（Parked Member Address, PM_ADDR）給它。PM_ADDR 是由 8 個位元所組成，因此在一個 Piconet 網路內，最多可容納 256 個處於 Park 狀態的裝置。 (D) AR_ADDR 位址 每一個處於 Park 狀態的 Slave，也會由 Master 分配到一個『存取要求位址』（Access Request Address, AR_ADDR）。在一個 Piconet 網路內，Slave 裝置之間所分配的 AR_ADDR 可能會相同，它並不是唯一識別值。AR_ADDR 位址的用法是，當 Slave 欲由 Park 狀態轉換到 Active 狀態時，必須利用這個位址向 Master 要求 Slave-to-Master 時槽（容後介紹）。 16-4-2 實體通道 在 Piconet 網路上，是由一個 Master 和若干個 Slave 裝置所構成，亦即形成一個最基本的 Bluetooth 網路。而 Bluetooth 技術以每一頻寬為 1 MHz，將 2.4 GHz 頻段劃分為 79 個頻道，而傳遞訊息時，便在這 79 個頻道（0, 1, …, 78）之間跳越；又因其每秒跳越 1600 次，所以每一個跳越的時槽為 625 μs。另一方面，Bluetooth 採用『分時雙工』（Time Division Duplex, TDD）的多工技術，這種 TDD 技術是針對跳頻之跳越次序來分配 Master 和 Slave 間的媒介使用權，其中偶數頻道是由 Master 裝置使用，而奇數頻道則由 Slave 傳遞訊息，這種技術稱之為『跳頻分時雙工』（Frequency Hopping-Time Division Duplex, FH-TDD），如圖 16-6 所示（k 為偶數）。當任何一方傳送資料時，並不完全將整個時槽佔滿，以減少雙方的干擾。
圖 16-6 跳頻分時雙工的傳輸方式 單就 TDD 多工技術來看，傳輸媒介的使用時間是以每個時槽 625 μs 為單位，將之劃分為若干個時槽，而通訊雙方則以交替方式使用時槽來傳送資料，亦即偶數時槽由 Master 傳送（又稱為 Master-to-Slave 時槽），而奇數時槽則由 Slave 使用（又稱為 Slave-to-Master 時槽）。FH-TDD 將這些時槽以頻率跳越方式，在不同的頻道上傳輸。 然而不論 Master 或 Slave，並非每次都只能使用一個時槽來傳送資料，有時為了提高傳輸速率，也可以連續使用 3 或 5 個時槽來傳送資料。連續傳送時槽可減少每一封包的封包標頭，如果每次都只能用一個時槽傳送，每一封包填入時槽時，都必須加入許多控制訊息。但由於 Master 和 Slave 各被限制只能固定於偶數或奇數時槽傳送，因此，連續時槽僅能為 1 個、3 個或 5 個，否則會跨越到對方（Master 跨到 Slave 或 Slave 跨到 Master）的起始傳送時槽。圖 16-7 為多時槽的傳送方式，k 為偶數表示 Master 傳送，若為奇數則表示 Slave 傳送。
圖 16-7 多時槽傳送方式 16-4-3 實體鏈路 就我們所瞭解，Bluetooth 技術具有同時傳送語音與資料的功能，主要是它的『實體鏈路』（Physical Link）提供有『電路交換』（Circuit-switch）與『封包交換』（Packet-switch）等兩種連線型態，以下分別說明這兩種連線型態。 (A) 同步連接導向連線 『同步連接導向』（Synchronous Connection-Oriented, SCO）連線是屬於電路交換的同步傳輸型態，並且是全雙工連線。當 Master 與某一個 Slave 之間建立 SCO 連線後，不管雙方是否有資料傳送，系統都會預留固定時槽給 Master 和 Slave 使用，而其它 Slave 就不能使用這些時槽來傳輸資料，如圖 16-8 所示。一般 SCO 連線都使用在語音傳輸，每一 SCO 連線都以一個時槽來傳送，並支援 64 Kbps 的傳輸速率（HV1 ~ HV3 格式）。當 SCO 連線建立後，Master 和 Slave 之間便可透過該連線來通話，而 Master 無需事先詢問（Polling）Slave。此外 SCO 連線是屬於點對點（Point-to-Point）的連線，也就是 Master 和 Slave 之間所建立的一對一直接連線。
圖 16-8 Master 與 Slave 之間的 SCO 連線傳輸 由於語音傳輸並不適合因受干擾而重新傳送，因此 SCO 連線並沒有自動重新傳送（ARQ）的機制；但有時候為了提高通話品質，可採用較嚴格的編碼技巧，或者採用較高等的『錯誤修正』（Error Correction）技術，因此有 HV1 ~ HV3 的封包格式，可依不同使用環境來選擇。一般來講，如果語音傳輸受到干擾，只要能分辨聲音即可，要求不會太高；但如果在數位音響部份，那就另當別論了。 (B) 非同步非連接連線 『非同步非連接』（Asynchronous Connection-Less, ACL）連線是屬於封包交換的非同步傳輸模式，也是屬於全雙工連線。在一個 Piconet 網路中，是由 Master 來分配 ACL 連線的使用，任何 Slave 傳送資料之前，必須經由 Master 的詢問（Polling）並同意之後才可以傳送資料。因為 Piconet 網路內只允許 Master 和 Slave 之間傳輸資料，所以 Bluetooth 提供 Master 和 Slave 之間有點對點（Point-to-Point）與單點對多點（Point-to-Multipoint）兩種連線。單點對多點連線表示可以由 Master 對多個 Slave 進行通訊，這是因為 Slave 和 Slave 之間的通訊必須透過 Master 轉送才行。另外 ACL 也提供 Master 裝置對所有 Slave 廣播的功能。 在實體層傳輸方面，SCO 和 ACL 連線都在跳頻的時槽中傳送，SCO 連線都是以單一時槽來傳輸，然而 ACL 可選擇多時槽方式傳輸。因為 SCO 的時槽都是固定的，所以 Master 在分配 ACL 時槽時，必須避開 SCO 的時槽，也就是說，SCO 的時槽優先權較高，而 ACL 只能選擇時槽還有空閒的時候才可以佔用。ACL 的多時槽設計是針對爆發性資料的傳輸使用，也就是說，Bluetooth 裝置常處於空閒狀態，當需要傳輸時，假使有大量資料要傳送、且此時又必須快速的傳送資料，才會使用多時槽傳輸。圖 16-9 為一個 Piconet 網路，內有 SCO 和 ACL 同時存在時，封包資料傳遞的情形，其中 SCO 連線已固定在某些時槽上傳送，ACL 僅能使用空閒的時槽。圖 16-9 中 ACL 時槽使用情況如下：其一是 Master 傳送一筆佔用三個時槽的資料給 Slave_2，緊接著下一個時槽由 Slave 回應確認訊號給 Master；另一則是 Master 詢問 Slave_2 是否有資料要傳送，而 Slave_2 則發送一個連續三個時槽的資料給 Master；其三是 Master 詢問 Slave_3，而 Slave_3 傳送一個時槽的資料給 Master。 這裡要特別注意的是，Bluetooth 網路是利用廣播方式來傳輸，當 Master 欲詢問或傳送訊息給某一個 Slave 時，便將訊號發射出去；每一個 Slave 收到封包後，由封包上的位址（AM_ADDR）來判斷是否是要傳送給自己，如果是自己的位址，便將該封包收取；否則便將其拋棄。
圖 16-9 SCO 與 ACL 連線的時槽傳輸情形 一般 ACL 連線都使用於資料傳輸，或者是經壓縮處理後的語音或視訊訊息，然而一般網路的上層通訊定（如 IP 或 PPP）都屬於較長封包的傳輸，如果下層利用較短封包的 Bluetooth 來實現，上層封包必須先分割為若干個較短的封包。為了要能合乎各種情況的應用，ACL 支援對稱和非對稱兩種傳輸速率。在非對稱模式下，雖然 Piconet 網路的頻寬為 1 Mbps，但須扣除其它控制訊號的傳輸，因此，下傳最高速率為 721 Kbps（Master-to-Slave），而上傳速率更只有 57.6 Kbps（Slave-to-Master）。在對稱模式下，上傳和下傳速率皆為 432.6 Kbps。然而為了提高傳輸資料的可靠性，ACL 提供有自動重送機制（ARQ），若接收端收到的資料在傳送中受到干擾而發生錯誤，則可要求對方重新傳送。 為了提高傳輸效益，在 Bluetooth 規格中允許 Master 和每一個 Slave 之間可建立 多條 SCO 連線，但僅能建立一條 ACL 連線。在建立或關閉 SCO 連線時，必須先建立 ACL 連線來傳遞控制訊號，但建立 ACL 連線比 SCO 連線來得容易。 16-4-4 封包格式 Bluetooth 將填入時槽內的訊息單元（未經編碼處理）稱為『封包』（Packet）（一般網路稱為訊框），隨著傳送不同的訊息（語音或資料），或使用時槽的多寡（1、3 或 5 個時槽），會衍生許多不同的封包格式，但它們都有一定的基本格式。圖 16-10 為 Bluetooth 的封包格式，包含了存取碼（Access Code）、標頭（Header）和承載（Payload）等三個主要欄位；但並不表示所有訊息封包都具有這些欄位，還是要依照該封包所傳送的訊息而定，以下分別說明各欄位的功能。
圖 16-10 Bluetooth 封包格式 (A) 存取碼（Access Code） 存取碼欄位包含了 Preamble、Sync Word 與 Trailer 等三個子欄位。其中 Preamble 和 Trailer 子欄位都是 4 個位元，是用來做直流補償（DC Offset Compensation）使用，如果 Sync Word 的最低位元（LSB）為 1 時，則 Preamble 為 1010；否則為 0101。Trailer 是由 Sync Word 的最高位元（MSB）決定，如果為 1，則 Trailer 為 1010；否則為 0101。 然而 Sync Word 欄位有 64 個位元長度，它的內容是由某一個裝置的 LAP位址經過計算處理後的值，這個計算處理是將 LAP 位址（24 位元）與虛擬亂數序列（Pseudo-Noise, PNS）經過 XOR 運算，並展開成為 64 位元。使用不同裝置的 LAP 位址來計算，會形成不同的 Access Code 型態，以下我們就由 Access Code 的型態來介紹它是由何種裝置計算得來； ● 『通道存取碼』（Channel Access Code, CAC）： Sync Word 是由 Master 裝置之 BD_ADDR 位址內的 LAP（Lower Address Part）計算而來。CAC 表示一個 Piconet 網路的識別碼，在同一個 Piconet 網路內的 Master 和 Slave 都用這個碼來表示，避免和其它 Piconet 互相干擾，同時防止他人竊聽。 ● 『裝置存取碼』（Device Access Code, DAC）：當 Master 對 Slave 發出『翻頁』（Paging）呼叫，或 Slave 回應 Master 的 Paging 呼叫的訊號時，其呼叫訊號的存取碼就是 DAC，DAC 是由 Slave 的 BD_ADDR 位址內的 LAP 計算所得的。 ● 『詢問存取碼』（Inquiry Access Code, IAC）：由某一特殊裝置的位址（LAP）計算得來。IAC 是 Master 查詢（inquiry）某一特殊裝置時所使用的查詢訊號。 (B) 標頭（Header） 由於標頭欄位是包含很重要的控制訊息，因此將原來的 18 位元經過 1/3 FEC（Forward Error Correction）編碼後，成為 54 位元長度。標頭欄位包含下列訊息（如圖 16-10 所示）： (1) AM_ADDR：長度為 3 位元。AM-ADDR 為『活動成員位址』（Active Member Address），亦即此封包的目的位址。任何一個 Bluetooth 裝置在 Bluetooth 網路上都有一個唯一的裝置識別碼，它是由 Access Code 欄位內的 CAC、DAC 或 IAC 位址，和 AM_ADDR 的組合而成。 (2) Type：長度為 4 個位元。Type 是用來描述封包的格式。在 Bluetooth 網路上，封包可分為共同（Common）、同步連接導向（SCO）與非同步非連接（ACL）等三種格式，如表 16-2 所示。 (3) Flow：長度為 1 個位元。Flow 旗號是用來針對 ACL 連線作流量控制之用，對 SCO 連線則沒有作用。當 Flow = 1 表示緩衝器還有空閒，對方可以繼續傳送資料；如果 Flow = 0，表示緩衝器已滿，要求對方暫停傳送。 (4) ARQN：長度為 1 個位元。ARQN（Automatic Request Not）是要求對方重新傳送的旗號， “1” 表示接收正常；“0” 則表示經錯誤檢查後，發現封包已發生錯誤，要求對方重送。 (5) SEQN：長度為 1 個位元。SEQN（Sequence Number Not）用來表示該封包是否為重送的封包，“1” 代表不是重送封包。SEQN 的功能必須和 ARQN 互相配合使用，它的功能就如同 TCP 協定中的 ACK 和 SYN 位元（有關 TCP 協定請參考第十三章說明），都是作為傳輸流量控制。 (6) HEC：8 位元的 HEC（Header Error Check）是針對封包標頭做錯誤控制的檢查碼。 上述的 Flow、ARQN 和 SEQN 等三個旗號都是針對 ACL 連線做傳輸流量的控制使用（採用 Stop-and-Wait 流量控制法，請參考第三章說明），如果該封包是使用於 SCO 連線，則這三個旗號便沒有任何功能。 表 16-2 Bluetooth 封包格式
(C) 承載（Payload） 隨著不同的封包型態，承載欄位的長度會有所不同（0 ~ 2745 位元），甚至承載欄位的格式也會不一樣，大略可區分為：單一時槽、多時槽和語音封包等三種格式，前兩者是針對資料封包，後者為承載語音使用。但單一時槽封包也有可能同時承載語音和資料（如 DV 封包）。單一時槽和多時槽都包含：『承載標頭』（Payload Header）、『承載實體』（Payload Body）、以及 CRC 等三個欄位，如圖 16-11 所示。 基本上，承載欄位所存放的內容，大多是由上層的協定資料單元（Protocol Data Unit, PDU）所包裝而來的，因此內容會和上層通訊協定較有關聯。如圖 16-11 所示，基頻協定的上層是 L2CAP、LMP 和 Audio 等三個協定，其中 LMP 是關於控制訊息；Audio 是語音通訊；而 L2CAP 是連結其它通訊協定使用，其中可能傳送資料或封包語音、視訊。有了這些概念後，我們再來看承載欄位內的子欄位會較容易，如圖 16-11 中無論單一時槽或多時槽（3 個或 5 個時槽），子欄位的功能都相同，如下敘述：
圖 16-11 Bluetooth 封包的承載欄位 ● L_CH（Logical Link Channel）：表示邏輯鏈路識別（以序號表示）。如果上層協定是 LMP，則 L_CH = 11；如果是 L2CAP 的起始連線，則 L_CH = 10；如果是 L2CAP 的連續連線或分段訊息（Fragment），則 L_CH = 01；其它邏輯鏈路為 00。 ● Flow：此旗號是用於 L2CAP 連線的流量控制。Flow = 1 表示還有緩衝器框間；Flow = 0 表示要求對方暫停傳送。 ● Length：表示此封包的承載長度，包含承載標頭（Payload Header）、承載實體（Payload Body）、以及 CRC 的長度，以位元組為單位。 如果封包格式為語音訊息，則承載內容為 240 位元的語音編碼，如圖 16-11 (c) 所示，典型的應用都是使用於 SCO 連線上。但 Bluetooth 網路允許語音和資料可同時傳送，也就是承載內可能同時存在語音編碼和資料的包裝，如表 16-2 中的 DV 封包。在 DV 封包的承載內，語音資料固定為 80 個位元，而一般數據資料的長度則為 150 個位元；但 DV 封包內沒有 Payload Header 欄位。 16-4-5 數據資料封包 由表 16-2 中可以發現有 6 種數據資料封包格式（如圖 16-11 (a) 與 (b) 所示），也都應用在 ACL 通訊連線上，我們將這些封包的特性整合於表 16-3，並分別敘述如下： ● DM1（Data-Medium Rate 1）：DM1 的 Payload 部份是由 18 個資訊位元組（Information Bytes）再加上 16 位元的 CRC 錯誤檢查碼所構成，這些訊息都接受過 2/3 FEC 編碼。資訊位元組內包含一個位元組的 Payload Header。DM1 佔用一個時槽。 ● DH1（Data-High Rate 1）：DH1 的 Payload 欄位包含 28 個資訊位元組及 16 位元的 CRC 檢查碼，兩者都沒有經過 FEC 編碼處理。資訊位元組中包含 1 個位元組的 Payload Header。DH1 佔用一個時槽。 ● DM3（Data-Medium Rate 3）：DM3 的 Payload 部份是由 123 個資訊位元組再加上 16 位元的 CRC 錯誤檢查碼所構成，這些訊息都接過 2/3 FEC 編碼。資訊位元組內包含 2 個位元組的 Payload Header。DM1 佔用一個時槽。 ● DH3（Data-High Rate 3）：與 DH1 非常相似，Payload 欄位是由 185 個資訊位元組與 16 個位元的 CRC 檢查碼所構成，兩者都沒有經過任何 FEC 編碼處理。Payload Header 為 2 個位元組，需佔用 3 個時槽。 ● DM5（Data-Medium Rate 5）：幾乎與 DM3 相同，Payload 部份是由 226 個資訊位元組再加上 16 位元的 CRC 錯誤檢查碼所構成，這些訊息都接過 2/3 FEC 編碼。DM5 的 Payload Header 為 2 個位元組，並佔用 5 個時槽。 ● DH5（Data-High Rate 5）：與 DH3 相似，Payload 欄位是由 341 個資訊位元組與 16 個位元的 CRC 檢查碼所構成，兩者都沒有經過任何 FEC 編碼處理。Payload Header 為 2 個位元組，共佔用 5 個時槽。 ● AUX1：與 DH1 相似，其 Payload 欄位包含 30 個資訊位元組，但沒有 CRC 檢查碼及任何 FEC 編碼處理。又 Payload Header 的長度為一個位元組，並佔用一個時槽。 表 16-3 ACL 連線的資料封包形式
在不同的環境下，可分別選擇上述各種不同的封包格式來包裝，但每一種封包格式都會佔用一個或二個位元組的 Payload Header。由表 16-3 可觀察到，在非對稱傳輸模式下，下傳最高可達 723.2 Kbps 的傳輸速率，但上傳則僅有 57.6 Kbps。所謂非對稱傳輸模式是『上行』（Up-Link）和『下行』（Down-Link）係採用不同的封包格式。譬如下行採用 DH5（佔用 5 個時槽），而上行使用 DH1（佔用 1 個時槽）的 ACL 通訊連線，表示如果沒有 SCO 連線佔用其它時槽的話，則每 6 個時槽週期中有 5 個下行時槽（DH5）及 1 個上行時槽（DH1），其上/下行傳輸速率計算如下（每秒 1600 個時槽）： 下行速率 = (339 Bytes) × (8 bits/Byte) × (1600 slots/sec ÷ 6 slots) = 723.2 Kbps 上行速率 = (27 Bytes) × (8 bits/Byte) × (1600 slots/sec ÷ 6 slots) = 57.6 Kbps 對稱傳輸表示上行與下行都採用同樣的封包格式，例如兩者都採用 DH5（佔用 5 個時槽）封包傳送，在沒有其它 SCO 連線的情況下，每 10 個時槽中就有 5 時槽上行、及 5 個時槽下行，其傳輸速率計算如下： 對稱傳輸速率 = (339 Bytes) × (8 bits/Byte) × (1600 slots/sec ÷ 10 slots) = 433.9 Kbps 16-4-6 語音封包 Bluetooth 封包格式有 5 種語音封包，如表 16-2 所示，這 5 種封包都是利用『同步連接導向』（SCO）連線來傳輸。語音封包都是佔用一個時槽，並且以對稱模式來傳輸。基本上，語音傳輸都是屬於交談式的對話，並不適合重新傳送的 ARQ/CRC 機制，Bluetooth 為了提高語音的品質及可靠度，所以將語音封包都先經過 FEC 編碼處理（如 HV1 和 HV2）。但有一些應用並不需要太好的音效品質，因此也可以採用沒有經過 FEC 編碼的 HV3 格式。但無論採用哪一種格式，都只用到一個時槽，因而傳輸速率都限制在 64 Kbps（雙向傳輸）以內，但以封包間隔來區分傳輸音效的良寡。各種封包的特性整合於表 16-4，並分別敘述如下： (1) HV1（High Quality Voice 1）：HV1 的 Payload 所存放的是將 10 個資訊位元組（Information Bytes）（80 個位元）經過 1/3 FEC 編碼後所成的 240 位元資料。HV1 支援 1.25 ms 的語音間隔，傳輸速率為 64 Kbps，封包間隔為 2。 (2) HV2（High Quality Voice 2）：HV2 的 Payload 所存放的是 20 個資訊位元組（160 個位元）經過 2/3 FEC 編碼後成為 240 位元的資料。HV2 支援 2.5 ms 的語音間隔，傳輸速率為 64 Kbps，封包間隔為 4。 (3) HV3（High Quality Voice 3）：HV3 的 Payload 中存放了 30 個資訊位元組（240 個位元），但沒有經過經過任何 FEC 編碼處理。HV3 支援 3.75 ms 的語音間隔，傳輸速率為 64 Kbps，封包間隔為 6。 (4) DV（Data Voice）：DV 的 Payload 分為語音和數據資料兩個部份，語音資料含有 80 個位元，沒有經過任何 FEC 編碼。數據資料包含 0 ~ 10 個資訊位元組與 16 個位元的 CRC 錯誤檢查碼，兩者都經過 2/3 FEC 編碼。由 DV 所傳送的資料並沒有 ARQ 機制，僅能以 CRC 來檢查資料的正確性。 表 16-3 ACL 連線的資料封包形式
由以上敘述可以發現，如採用較高品質的 HV1 來傳輸語音，通訊雙方都是每兩個時槽傳送一個 HV1 封包，等於將時槽全部佔滿（SCO 連線），也就無法再建立其它通訊連線了（SCO 或 ACL 連線）。相對的，使用傳輸品質較差的 HV3，通訊雙方的時槽間隔為 6，亦是每 6 個時槽才只佔用 2 個時槽，剩下來 4 個時槽可用來建立其它 SCO 或 ACL 連線。至於到底要選用何種封包格式，則可依使用環境來決定。 16-4-7 錯誤控制 『錯誤控制』（Error Control）在一般通訊系統中是非常重要的機制。接收端收到訊息後，如何來判斷該訊息是否正確？假使確定訊息已發生錯誤，應以何種方式來要求對方重送、或者自行將錯誤修正，這就是錯誤控制的功能。一般網路上所傳遞的訊息採用長訊框方式居多，且大多是採用『錯誤檢出』（Error Detection）方式，如 CRC 檢查機制。當接收端由錯誤檢出機制發現所接收的訊息已發生錯誤，如何要求對方重送，這便是『自動重複請求』（ARQ）機制。如果傳輸端傳輸訊息之前，將訊息做特殊的編碼（如 1/3 FEC），接收端收到訊息後，不但可以檢查出該訊息是否發生錯誤，並且可以將錯誤修正回來，這就是『錯誤修正』（Error Correction）機制。雖然錯誤修正的功能較強，但必須付出較龐大的代價，經過錯誤修正編碼的資料量，會比原來的資料多了許多，也就是會浪費許多頻寬來傳輸這些多餘的資料，這些多餘的資料又稱之為『多餘碼』（Redundancy Code）。有關 CRC 和 ARQ 機制請參考第三章說明，這裡不再重複。 Bluetooth 的通訊環境是在 2.4 GHz ISM 頻段上傳輸，目前這個頻段還有許多其它網路在使用，訊號之間干擾非常嚴重，雖然採用跳頻技術可以避免其它訊號的干擾，但也無法達到百分之一百的避免。 因此，Bluetooth 制定了嚴謹的錯誤控制機制，除了錯誤檢出的自動重複請求（ARQ 機制）外，也有錯誤修正的功能。基本上，錯誤修正是針對不適合重送的語音資料，而 ARQ 機制是針對可以重送的數據資料。 Bluetooth 在 Baseband 規範中制定了 1/3 FEC（Forward Error Correction）和 2/3 FEC 兩種『順向錯誤修正』機制。1/3 FEC 表示資料經過錯誤修正編碼後，會成為原來資料的三倍，它的傳輸效益便剩下 1/3。譬如，80 位元的資料經過 1/3 FEC 編碼後，便成為 240 個位元長的訊息，其實真正的資料只有訊息的 1/3。2/3 FEC 編碼表示編碼後，原來資料只佔 2/3，譬如資料長度為 10 個位元，編碼後成為 15 個位元。基本上 1/3 FEC 的錯誤修正能力比 2/3 FEC 強，但相對應的，1/3 FEC 有較長的多餘碼，也會影響傳輸效益，如 HV2 的傳輸效益比 HV1 高（有關 FEC 演算法請參考 “Error Control Coding: Fundamentals and Applications”, SHU LIN）。
|
翻轉工作室：粘添壽
電腦網路與連結技術：
翻轉電子書系列：
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
