杜智敏 ，謝維波 ，楊大力

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

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

1 語音傳輸模型

語音在AdHoc網(wǎng)絡(luò)中傳輸?shù)幕灸Ｐ腿鐖D1所示。音頻設(shè)備采集到的模擬語音信號必須經(jīng)過采樣量化等處理手段轉(zhuǎn)換成數(shù)字信號，然后經(jīng)過壓縮并打包成某種網(wǎng)絡(luò)數(shù)據(jù)包格式，之后在AdHoc網(wǎng)絡(luò)中進(jìn)行傳輸。到達(dá)目的端系統(tǒng)后首先經(jīng)過網(wǎng)絡(luò)協(xié)議棧解包，得到壓縮過的數(shù)字語音數(shù)據(jù)，之后經(jīng)過解壓縮等處理過程，得到原始語音數(shù)據(jù)。

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

2 AdHoc網(wǎng)絡(luò)模型

IEEE 802.11作為無線通信的官方標(biāo)準(zhǔn)僅僅考慮到了單跳的網(wǎng)絡(luò)，因此很有必要為多跳無線網(wǎng)絡(luò)開發(fā)相應(yīng)的路由協(xié)議。這些路由協(xié)議決定如何通過其他節(jié)點(diǎn)對目的節(jié)點(diǎn)不在傳輸域內(nèi)的信息進(jìn)行轉(zhuǎn)發(fā)。

圖1 基于AdHoc網(wǎng)絡(luò)的語音通信基本模型

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

這里使用AODV(AdHoc on-Demand Distance Vector)[1-2]協(xié)議對AdHoc網(wǎng)絡(luò)的實(shí)時通信性能進(jìn)行測試。AODV借鑒了DSR協(xié)議的路由發(fā)現(xiàn)和維護(hù)概念，以及DSDV協(xié)議的序列號和發(fā)送周期性Hello包的機(jī)制。其主要路由機(jī)制如下：

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

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

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

3 AODV協(xié)議對網(wǎng)絡(luò)性能的影響

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

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

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

圖2 鏈路失效檢測時間

①節(jié)點(diǎn)1在收到第2個Hello包之后，實(shí)際鏈路斷開，而此時AODV路由協(xié)議由于收到了Hello包，認(rèn)為鏈路依然有效。

②在節(jié)點(diǎn)1收到第2個Hello包之后一個HELLO_INTERVAL時，實(shí)際鏈路斷開，而AODV協(xié)議并不認(rèn)為鏈路斷開，而是會發(fā)送第二個Hello包來確認(rèn)鏈路狀況。由于鏈路失效時間不可預(yù)知，可認(rèn)為其是介于HELLO_INTERVAL和 2×HELLO_INTERVAL之間的一個隨機(jī)數(shù)。由于相對路由變化時間來說路由發(fā)現(xiàn)時間可以忽略，可對其定義如下：

4 性能評估測試

4.1 測試環(huán)境構(gòu)建

本文使用4臺安裝Linux系統(tǒng)的筆記本作為實(shí)驗設(shè)備。路由協(xié)議使用開源的aodv-uu-0.9.6.tar.gz[3]，應(yīng)用程序為自己編寫的雙工語音通信程序（使用udp進(jìn)行語音通信，由語音錄制、語音壓縮、語音解壓縮、語音播放4個線程構(gòu)成）。測試環(huán)境構(gòu)建流程為：

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

設(shè)置完網(wǎng)卡后，可以使用ifup wlan0來查看網(wǎng)卡是否設(shè)置成功。

(2)安裝路由協(xié)議

(3)構(gòu)建網(wǎng)絡(luò)拓?fù)?/p>

將4臺筆記本直線擺放在實(shí)驗桌面上，IP地址分配依次為 192.168.2.5～192.168.2.8（4節(jié)點(diǎn)結(jié)構(gòu)，3節(jié)點(diǎn)網(wǎng)絡(luò)拓?fù)渑c此類似）。

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

其中l(wèi)aptop_mac為要屏蔽的laptop的mac地址。

為實(shí)現(xiàn) laptop1經(jīng)過 laptop2，再經(jīng)過 laptop3，最后到達(dá)laptop4的多跳效果，需要讓laptop1屏蔽掉其到laptop3和laptop4的直接通路。在其上執(zhí)行命令（其中以#開頭的表示在超級用戶權(quán)限執(zhí)行的命令）：

表1 3個節(jié)點(diǎn)丟包率和延時

表2 4個節(jié)點(diǎn)丟包率和延時

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

4.2 性能測試方案設(shè)計及測試結(jié)果分析

(1)路由發(fā)現(xiàn)時間

按照上面步驟設(shè)置好無線網(wǎng)卡后，啟動AODV路由協(xié)議：

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

測試可得，3個節(jié)點(diǎn)路由發(fā)現(xiàn)時間為 6 ms，4個節(jié)點(diǎn)路由發(fā)現(xiàn)時間為10 ms。相對數(shù)據(jù)包發(fā)送延時來說，基本可以忽略。

(2)AdHoc網(wǎng)絡(luò)丟包率和延時

使用ping命令向目的節(jié)點(diǎn)發(fā)送1 000個默認(rèn)大小(56 B)的數(shù)據(jù)包。命令為：ping-c 1000-i interval 192.168.2.8。其中interval為發(fā)送兩次icmp數(shù)據(jù)包之間的時間間隔。

網(wǎng)絡(luò)丟包率和延時測試結(jié)果如表1、表2所示。

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

而 ALLOWED_HELLO_LOSS 為 2，HELLO_INTERVAL為 1 000 ms，于是 DELETE_PERIOD默認(rèn)為 3 000 ms。 即AODV協(xié)議每隔3 s會刪除在這段時間內(nèi)都未使用的路由，而發(fā)送數(shù)據(jù)包時隙為5 s，由于上次使用的路由已被刪除，于是每次發(fā)送都需要重新發(fā)現(xiàn)路由，最終導(dǎo)致了嚴(yán)重的網(wǎng)絡(luò)丟包率。

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

在 laptop1、laptop3（3 節(jié)點(diǎn)網(wǎng)絡(luò)）和 laptop4（4 節(jié)點(diǎn)網(wǎng)絡(luò)）運(yùn)行語音通信程序，并在程序中增加數(shù)據(jù)包計數(shù)器來統(tǒng)計丟包率。

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

表3 語音傳輸丟包率

本文深入闡述了AdHoc網(wǎng)絡(luò)中的語音傳輸模型和AdHoc基本模型，詳細(xì)分析了AODV路由協(xié)議對AdHoc網(wǎng)絡(luò)性能的影響以及語音評價標(biāo)準(zhǔn)。最后實(shí)際搭建了AdHoc網(wǎng)絡(luò)，并對其通信性能及其上的語音通信性能進(jìn)行評估測試。本文旨在幫助廣大研究人員對AdHoc網(wǎng)絡(luò)性能有更深入的理解。

[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.