AdHoc網絡中語音傳輸的分析及性能測試*

杜智敏 ，謝維波 ，楊大力

(1.華僑大學 計算機科學與技術學院，福建 廈門361021；2.華僑大學 廈門軟件園嵌入式技術開放實驗室，福建 廈門361008)

隨著無線通信技術和嵌入式技術的飛速發展，AdHoc網絡技術及其上的多媒體應用成為一個研究熱點。由于實驗條件等限制，目前針對AdHoc網絡的研究大都基于NS（Network Simulator）、GloMoSim 等仿真工具，研究成果往往理論有余，而實踐稍顯不足。為了深入研究AdHoc網絡中的語音通信技術，構建實際AdHoc網絡，對該實際網絡環境及其上語音通信性能的評估分析研究就顯得十分必要。

1 語音傳輸模型

語音在AdHoc網絡中傳輸的基本模型如圖1所示。音頻設備采集到的模擬語音信號必須經過采樣量化等處理手段轉換成數字信號，然后經過壓縮并打包成某種網絡數據包格式，之后在AdHoc網絡中進行傳輸。到達目的端系統后首先經過網絡協議棧解包，得到壓縮過的數字語音數據，之后經過解壓縮等處理過程，得到原始語音數據。

決定語音質量的主要因素是編解碼器的選擇，其次是網絡傳輸性能的影響。網絡延時和丟包對語音通信質量造成的影響在AdHoc網絡中一直是個技術瓶頸。

2 AdHoc網絡模型

IEEE 802.11作為無線通信的官方標準僅僅考慮到了單跳的網絡，因此很有必要為多跳無線網絡開發相應的路由協議。這些路由協議決定如何通過其他節點對目的節點不在傳輸域內的信息進行轉發。

圖1 基于AdHoc網絡的語音通信基本模型

大量針對不同路由協議的模擬已經通過不同的模擬器進行了模擬。但是模擬器建立的是一種理想模型，并不能將實際情況中的所有因素考慮在內，所以其結果同樣是一種理想結果，并不能作為商業應用的參考。

這里使用AODV(AdHoc on-Demand Distance Vector)[1-2]協議對AdHoc網絡的實時通信性能進行測試。AODV借鑒了DSR協議的路由發現和維護概念，以及DSDV協議的序列號和發送周期性Hello包的機制。其主要路由機制如下：

(1)路由發現機制：當一個節點要與另外一個節點通信時，它首先查看自己的路由表，看到達該目的節點的路由是否存在，若不存在，則初始化一個路由發現過程（AODV創建并廣播一個RREQ控制包，并設置一個定時器來等待回應數據包RREP）。所有收到RREQ控制包的節點都會比較該包的ID，看是否以前曾經收到過。若非第一次收到，則直接丟棄該控制包。

(2)路由維護機制：當一個路由建立好后，就需要源節點來對其進行維護。節點的移動只會影響到途經該節點的路由，并不對網絡造成全局影響。源節點在通信過程中的移動會造成它與當前使用路由的下一跳之間的連接斷開，此時，它將會重新廣播一個RREQ包來發現路由。如果中間節點與其下一跳之間的連接斷開，它會發送一個RERR包給其（當前路由）前驅節點，并將到達該目的節點的路由標記為無效（被標記為無效的路由將于一段固定時間之后被丟棄）。其前驅節點收到RERR包后，同樣將該條路由標記為無效，并將該RERR發送給自己的前驅節點。

(3)Hello包機制：在規定時間內，如果沒有數據包傳輸，節點就會廣播發送Hello消息給其鄰居節點來對本地連接進行更新。Hello消息的內容包括節點的IP地址及當前序列號等。由于該信息不需要被轉發，它們的ttl值都為 1。

3 AODV協議對網絡性能的影響

(1)端到端延時：由于AODV為被動路由協議，所以在第一次數據傳輸時，如果沒有有效路由，則會啟動發現路由機制，于是引入了發現路由延時。發現路由延時的大小主要取決于端到端需要經過的跳數，當然不同的AODV實現版本之間的發現路由延時也會有所差別。

(2)路由變化延時：該延時是指從當前工作路由失效到重新發現并啟用新的有效路由之間的時間。該延時取決于 ALLOWED_HELLO_LOSS×HELLO_INTERVAL。 可以通過調整這兩個參數來降低該延時。ALLOWED_HELLO_LOSS默認為2，如果調整為 1，由于無線信道的不穩定，時不時地信道狀況不好會導致Hello包的丟失，由于ALLOWED_HELLO_LOSS調整為1，于是造成了路由協議認為鏈路已損壞，而實際鏈路并未斷開的狀況的出現。

分析圖2所示的情況。假設ALLOWED_HELLO_LOSS的默認值為2，則AODV路由協議在2×HELLO_INTERVAL未收到Hello包時就會認為該鏈路已經斷開。此時有兩種極端情況：

圖2 鏈路失效檢測時間

①節點1在收到第2個Hello包之后，實際鏈路斷開，而此時AODV路由協議由于收到了Hello包，認為鏈路依然有效。

②在節點1收到第2個Hello包之后一個HELLO_INTERVAL時，實際鏈路斷開，而AODV協議并不認為鏈路斷開，而是會發送第二個Hello包來確認鏈路狀況。由于鏈路失效時間不可預知，可認為其是介于HELLO_INTERVAL和 2×HELLO_INTERVAL之間的一個隨機數。由于相對路由變化時間來說路由發現時間可以忽略，可對其定義如下：

4 性能評估測試

4.1 測試環境構建

本文使用4臺安裝Linux系統的筆記本作為實驗設備。路由協議使用開源的aodv-uu-0.9.6.tar.gz[3]，應用程序為自己編寫的雙工語音通信程序（使用udp進行語音通信，由語音錄制、語音壓縮、語音解壓縮、語音播放4個線程構成）。測試環境構建流程為：

(1)配置無線網卡（以laptop1為例）

設置完網卡后，可以使用ifup wlan0來查看網卡是否設置成功。

(2)安裝路由協議

(3)構建網絡拓撲

將4臺筆記本直線擺放在實驗桌面上，IP地址分配依次為 192.168.2.5～192.168.2.8（4節點結構，3節點網絡拓撲與此類似）。

由于筆記本自帶無線網卡傳輸范圍比較大，laptop1和laptop4可以直接通信，而不需經過laptop2和laptop3，而室內空間也有限，所以為實現laptop1→laptop2→laptop3→laptop4多跳效果，這里需要使用Linux系統的防火墻工具iptables[4]。其命令格式為：

其中laptop_mac為要屏蔽的laptop的mac地址。

為實現 laptop1經過 laptop2，再經過 laptop3，最后到達laptop4的多跳效果，需要讓laptop1屏蔽掉其到laptop3和laptop4的直接通路。在其上執行命令（其中以#開頭的表示在超級用戶權限執行的命令）：

表1 3個節點丟包率和延時

表2 4個節點丟包率和延時

以同樣的方式讓laptop2屏蔽掉其到laptop4的直接通路，讓laptop3屏蔽掉其到laptop1的直接通路，讓laptop4屏蔽掉其到laptop1和laptop2的直接通路。

4.2 性能測試方案設計及測試結果分析

(1)路由發現時間

按照上面步驟設置好無線網卡后，啟動AODV路由協議：

使用 ping命令從 laptop1發送數據包到 laptop3（和laptop4），此時AODV會啟動發現路由過程，并建立路由表。路由發現時間可由AODV路由協議的日志中得出（rreq_create啟動到 aodv_socket_process_packet對 RREP包進行處理）。

測試可得，3個節點路由發現時間為 6 ms，4個節點路由發現時間為10 ms。相對數據包發送延時來說，基本可以忽略。

(2)AdHoc網絡丟包率和延時

使用ping命令向目的節點發送1 000個默認大小(56 B)的數據包。命令為：ping-c 1000-i interval 192.168.2.8。其中interval為發送兩次icmp數據包之間的時間間隔。

網絡丟包率和延時測試結果如表1、表2所示。

從測試結果可知，當發包時隙為5 s時，丟包率暴增到一半以上。這是AODV路由協議作用的結果，正常情況下應該是發包頻率越慢，丟包率越低。由于AODV路由協議維護有效路由有個定時器：ACTIVE_ROUTE_TIMEOUT(默認為 3 000 ms)和 DELETE_PERIOD。 DELETE_PERIOD計算公式[5]為：

而 ALLOWED_HELLO_LOSS 為 2，HELLO_INTERVAL為 1 000 ms，于是 DELETE_PERIOD默認為 3 000 ms。 即AODV協議每隔3 s會刪除在這段時間內都未使用的路由，而發送數據包時隙為5 s，由于上次使用的路由已被刪除，于是每次發送都需要重新發現路由，最終導致了嚴重的網絡丟包率。

(3)語音通信丟包率測試

在 laptop1、laptop3（3 節點網絡）和 laptop4（4 節點網絡）運行語音通信程序，并在程序中增加數據包計數器來統計丟包率。

對比表3所示丟包率測試結果和icmp包的丟包率測試結果，可以看出3個節點的網絡中音頻數據傳輸類似時隙為0.1～0.2之間的icmp包的傳輸，但是4個節點時相當于時隙為0.6的icmp包的傳輸。該結果間接表示4節點之間的語音傳輸延時大大增加，這也是無線AdHoc網絡的一大技術瓶頸。

表3 語音傳輸丟包率

本文深入闡述了AdHoc網絡中的語音傳輸模型和AdHoc基本模型，詳細分析了AODV路由協議對AdHoc網絡性能的影響以及語音評價標準。最后實際搭建了AdHoc網絡，并對其通信性能及其上的語音通信性能進行評估測試。本文旨在幫助廣大研究人員對AdHoc網絡性能有更深入的理解。

[1]AODV[DB/OL].http：//moment.cs.ucsb.edu/AODV/.

[2]PERKINS C，ROYER E.AdHoc on-Demand distance vector routing-RFC3561[C].2003：1-38.

[3]AODV-UU[S/OL].http：//sourceforge.net/projects/aodvuu/.

[4]Netfilter/Iptables[S/OL].http：//www.netfilter.org.

[5]Lu Yi，Zhong Yuhui，BHARGAVA B.Packet loss in mobile AdHoc networks[R].2003.