第二章、 文獻探討
2.5 語音傳輸於無線感測網路相關文獻探討
關於語音封包傳輸於 ZigBee 的研究，目前有眾多的論文提出一些解決方法，
以下本論文將會針對不同類型的設計方式進行一些介紹。首先介紹的是由學者
R. Mangharam 等人在[18]的研究中，提出一個運用在緊急需求及佈建不易的礦坑 環境下開發 ZigBee 語音通訊技術，使用 ADPCM 編碼器做語音編解碼，並且可 支援多種編碼率(Multi-rate)。其硬體使用 Atmel ATmega32[19]微處理器，除了利 用 IEEE 802.15.4 傳送語音封包之外，還利用 AM 頻帶做時間同步。但由於語音 通訊是頻繁且隨機的，大量的語音資料可能造成微處理器無法負荷，並同時進行 編解碼與封包傳送，此方法未對流量控制機制加以考量，如此可能導致封包錯誤 率(Error Rate)提高。
H. Y. Song 等人在[20][21]提出修改 IEEE 802.15.4 PHY/MAC 標準所使用的參 數 ， 簡 化 MAC Header 並 將 MAC Payload 調 整 為 102 Bytes ， 並 採 用
Non-Acknowledgement 模式，藉此提高頻寬使用率已達到多方同時通話的功能。
除此之外，使用 G.729.A 編碼器將語音壓縮成 8kbps，並以每 20 毫秒傳送 20 Bytes 速率進行傳送。實驗以點對點全雙工(Peer to peer full-duplex)方式進行，分別量測 室內短距離傳輸與室外長距離傳輸之封包遺失率，以及多方同時傳輸之封包遺失 率，由其量測結果中，點對點全雙工之封包在 22 公尺的距離時，遺失率維持在 2%內，不過在 27 公尺的距離時，封包遺失率大幅提高至 20.13%。
29
L. Li 等人在[22]中提出一個以語音品質為導向之語音傳輸系統，其運作的方 式主要是每個節點隨時監控其封包遺失率與延遲，根據連線狀態而動態調整語音 壓縮比，以維持語音傳輸品質。並提出一個分散式權限控制演算法(Distributed
Admission Control Algorithm)，計算各區域中每個節點可提供的傳輸量，以分配資 料傳輸頻寬，當有更多節點加入語音傳輸時，可以動態調整整體網路效能。
T. Facchinetti 等學者在[23]中提出一個針對即時語音串流(Real-time Voice Streaming)特性，利用 Moving Picture Experts Group(MPEG-Model I) 與快速傅立 葉轉換(Fast Fouier Transform)將聲音壓縮，並實作於嵌入式系統。除此之外，作 者也提出固定優先權(Fixed Priority)演算法，給予每個封包送達 的時間限制
(Deadline)，以維持即時語音串流品質。在實驗結果方面其取樣、壓縮、封裝和傳 送之延遲時間確實可維持在即時傳輸的時間限制內，並提供尚可語音品質。
D. Brunelli 等學者在[24]提出 ZigBee-like 協定堆疊，其主要的網路層(Network Layer, NWK) 、 應 用 支 援 子 層 (Application Support Sub-layer, APS) 和 應 用 Frame(Application Framework, AF)之欄位格式依然延續 ZigBee 標準，但在 MAC 層和 PHY 層則採用自訂欄位。除此之外作者也提出空間再利用(Spatial Reuse)演 算法，其主要目的是將感測節點之傳輸範圍盡量縮小，以避免和其他節點競爭通 道。在其系統架構中將 Tx 與 Rx 各建置兩組緩衝存儲器(Buffer)，以確保訊號處 理與串流傳送皆可獨立運作，以降低延遲時間。
30
在[26]研究中，Kyriakos K.等作者提出流量管理機制以支援即時傳輸於高度 難以預測的無線感測網路。該論文設計一套名為 SUPORTS 的方法，藉由持續監
[32]中，提到如何做語音品質評量的方法。該作者提出利用結合 PESQ 與 E-Model 語音品質量測方法，除了具有 PESQ 客觀且準確的評分外，並考量點對點延遲，
再套用 E-Model 計算以獲得更精準的語音品質量測。在介紹了眾多的論文及其方
31
法之後，將在第四章中說明關於流量控制於非對等頻寬之語音傳輸於無線感測網 路，其中包括系統架構與運作機制，以達到提升整體傳輸量與降低延遲時間之目 標，最終以獲得良好的語音品質。
32
33
第三章、於無線感測網路中傳送語音封包之機制
如同在 2.1 節至 2.3 節所提到基於藍芽與 ZigBee 語音閘道器所需要的技術，
如要將這些技術實作在嵌入式系統中，並且滿足語音服務品質的要求，那麼一定 會遇到一個問題，如何達到延遲、傳輸量、抖動等各方面的要求。在第三章討論 的相關參考文獻當中，雖然有針對語音傳輸於無線感測網路之研究有提出可行的 設計，但相對的則會增加或犧牲其延遲或是語音品質，除此之外，並沒有利用語 音評估系統如 MOS 等，評估語音品質的好壞。為了改善這個現象，因此本論文 將要設計一個可傳輸於藍芽與 ZigBee 之間的語音閘道器，並結合流量控制機制 以有效降低封包遺失率、延遲與抖動率。在進入各項機制的說明之前，將先介紹 關於語音閘道器的運作模式，最後說明各機制在系統中的位置與功能。
34
3.1 語音閘道器系統
本研究提出的 BZVG 系統架構，如圖 10 所示，其中包括藍芽模組、Speex 編解碼器、流量控制機制與 Xbee[33]模組。BZVG 中的藍芽模組將與使用者的藍 芽耳機進行連線與傳輸，Speex 編解碼器將對語音進行低碼率的編解碼，而流量 控制機制包括三個部分，分別為 Traffic Shaping Buffer(TSB)、Leaky Bucket 與 Xbee 硬體流量控制架構，Xbee 模組負責傳送與接收語音資料於無線感測網路，章節 3.2 與 3.3 有更詳細的說明。
圖 10 系統架構圖
圖 11 為本論文單向語音傳輸流程，將依序說明每個步驟流程。首先一開始藍 芽耳機的麥克風將收錄人的聲音，經由 PCM 將類比訊號(1)轉換成數位訊號(2)，
而數位訊號將送至藍芽內建的 Subband 編碼器進行編碼(3)，經過編碼之後的語音 資料將透過無線藍芽傳送至 BZVG 的藍芽接收器(4)，以上步驟將於藍芽耳機內 進行。當 BZVG 的藍芽接收器接收到語音資料後，須先由藍芽 Subband 解碼器進 行解碼(5)，才可將語音資料解讀出來，由於藍芽的 Data Rate 為 64 kbps，必須壓 縮成較小的 Data Rate 才可於無線感測網路傳輸，因此本研究採用 Speex 窄頻模
35
式(Narrow Mode)，編碼率為 11 kbps，於(6)進行 Speex 的編碼，每個音 Frame 為
20 毫秒的 160 個取樣。
由於藍芽端具有較高頻寬，將產生大量的資料，因此當 Speex 編碼後的語音 封包將暫存於 TSB 中，做為緩衝區塊(7)。接著由(8)Leaky Bucket 依據 Xbee 內部
Buffer 的狀態(9)，進行輸出頻寬的調整，(10)(11)Xbee 微處理器為執行將 Buffer 的資料送至 Xbee 收發器，傳輸於無線感測網路中(12)。
當接收端之 BZVG 的 Xbee 收發器接收到資料之後(13)，微處理器資料先暫存 於 Buffer(14)，BZVG 會將資料送至 Speex 解碼器進行解碼(15)，並傳送至藍芽模 組(16)。藍芽將對語音資料進行解碼(17)，並傳輸至接收端藍芽耳機(18)，，最終
Bluetooth and ZigbeeVoice Gateway
Xbee Buffer
Bluetooth and ZigbeeVoice Gateway
Xbee Buffer
36
得精準的語音評量分數。下列將針對本論文所提出的結合藍芽與 ZigBee 於語音 閘道器的系統架構與運作方式，做詳細的介紹與說明。
在本論文中，我們提出一個利用 ZigBee 傳輸協定來進行語音傳輸於無線感測 網路的架構，建構可應用於非對等頻寬之語音傳輸系統。在系統傳輸架構方面，
提出以點對點(Peer to Peer)傳輸的方式，當作語音傳輸的骨幹，因此在本論文並 不討論多點跳耀(Multi-hop)的傳輸架構。
37
3.2 Traffic Shaping Buffer 語音資料暫存與拋棄機制
本論文在語音閘道器內部之語音資料暫存機制的設計上，主要是為了解決藍 芽與 ZigBee 因為傳輸速率差異過大，造成語音資料遺失的問題。在傳輸速率差 異的改進上，除了維持 Xbee 的高吞吐量之外，更進一步的方法為結合語音資料 暫存的方式，語音資料暫存架構如圖 12 所示。將經由 Speex 所編碼完成的資料，
暫存於快閃記憶體(Flash Memory)，透過暫存語音資料以避免因為 ZigBee 網路頻 寬較小無法順利傳送，而造成資料損壞。
圖 12 閘道器流量控制架構圖
本研究提出 Traffic Shaping Buffer(TSB)的功能為儲存語音資料，如圖 13 所 示。由於 XBee 模組傳送資料至無線感測網路之頻寬並非為固定速率(Constant
Bit Rate, CBR)，而閘道器的藍芽接收端則是以較高且固定速率傳送資料製 TSB，
因此 TSB 的作用為盡可能地暫存編碼後的語音資料，提供 Leaky Bucket 以穩定 的速率送至 XBee 模組，以確保語音資料的完整性，並且避免語音資料於閘道 器內發生壅塞。
38
由於當無線感測網路傳輸狀況不佳，造成語音資料持續累積於 TSB，使得 TSB 儲存量已達最大容量門檻值(Upper Bound)時，將會造成 TSB 無法再儲存新進的 資料。為了改善此問題，必須將已儲存在記憶體內部的語音資料先進行拋棄，以 容納後續新進語音資料。在拋棄機制的設計方面，本論文參考 Random Early
Detection(RED)[34]中的封包拋棄機制，但由於 RED 選擇拋棄封包的方式為隨機，
考量到隨機方式可能發生拋棄之封包過於集中於某一語音片段，可能造成重要通 話內容無法被傳達，甚至造成語音品質低落。因此本研究採用週期性(Periodic)拋 棄機制，達到拋棄之語音片段缺口可以平均的分散，以確保所有重要通話內容皆 可被辨別。
圖 13 Traffic Shaping Buffer 架構圖
本 系 統 在 TSB 中 設 立 兩 個 門 檻 值 分 別 為 Upper Bound(UB) 和 Lower Bound(LB)，而門檻值之設定，則是依據 M. Kwon 等學者於[35]的研究中，說明
39
了佇列延遲和輸出頻寬是各自獨立並且成反比，當需要處理的資料增加，且輸出 頻寬不足或越來越小時，佇列延遲將會越長。因此，可以表示佇立大小可由延遲 與輸出頻寬相乘取得，如公式(11)所示：
(11) 預期佇列大小
預期延遲
為輸出頻寬
本論文根據此一公式，結合 ITU-T G.114[36]標準規定中所分析之延遲與 E-Model R-Factor 對應圖，如圖 14 所示。在 150 毫秒時，語音品質為最佳(Users very satisfied)，在 400 毫秒時，語音品質為勉強可接受(Some users dissatisfied)的最低 範圍。而 Xbee 輸出頻寬為 108kbps，導入公式(11)，如公式(12)所得到的 LB 門檻 值為：
(12) UB 門檻值，如公式(13)所示：
(13)
40
圖 14 E-model 與絕對延遲(Absolute delay)影響對照圖[36]
TSB 所儲存的資料為 Speex 編碼後的資料格式，因此必須先識別出 Speex 的 表頭，才可正確地判斷出每一個封包，而拋棄之標籤則置於 Frame 表頭之前。在
Speex 的標準規格[7]當中，制訂出 Speex Frame 表頭中的種類、變數型態與大小，
如表 8 所示。其中 Speex 表頭為 8 個 Bytes，根據 Speex 所制定的表頭，系統找 出每個 Speex Frame 的起始數據，如表 6 所示，每一個經過 Speex 編碼後的 Frame 表頭皆由.F 為起始值。因此，根據判斷 Frame 表頭的起始值，TSB 即可識別出是 否為 Frame 表頭的起始數據，並加入拋棄標籤。
具有拋棄標籤之 Frame 其起始字元為*，如表 7 ，由於拋棄標籤僅作用於 TSB 之內，因此當具有拋棄標籤之 Frame 在送至 Leaky Bucket 之前並沒有執行拋棄程
具有拋棄標籤之 Frame 其起始字元為*，如表 7 ，由於拋棄標籤僅作用於 TSB 之內，因此當具有拋棄標籤之 Frame 在送至 Leaky Bucket 之前並沒有執行拋棄程