劉玉梅，馬文進

哈爾濱工程大學 信息與通信工程學院，黑龍江 哈爾濱 150001

隨著物聯(lián)網(wǎng)技術(shù)的發(fā)展，嵌入式系統(tǒng)在基礎(chǔ)與應(yīng)用研究領(lǐng)域越來越重要[1]。嵌入式軟件系統(tǒng)的主要核心部件為微型嵌入式[2]處理器，硬件系統(tǒng)的框架主要包括硬件處理器、硬件存儲器、應(yīng)用軟件和硬件I/O。嵌入式系統(tǒng)具有強大的實時性、系統(tǒng)內(nèi)核小、功能專用性強、軟件系統(tǒng)功能精簡等優(yōu)點，因此其應(yīng)用已經(jīng)深入到國防、科研以及日常生活等各個領(lǐng)域中[3]。

無線自組網(wǎng)按需距離矢量路由協(xié)議(Ad hoc on-demand distance vector routing，AODV)[4]是應(yīng)用于無線Ad-Hoc 網(wǎng)絡(luò)[5]中進行路由選擇的路由協(xié)議，它能夠?qū)崿F(xiàn)單播和多播，同時該協(xié)議是Ad Hoc 網(wǎng)絡(luò)中按需生成路由方式的典型協(xié)議，目前Ad Hoc 網(wǎng)絡(luò)中的AODV 協(xié)議的性能主要利用NS2 仿真軟件在理想環(huán)境中對該協(xié)議的端對端平均時延、路由開銷等性能進行評估，但是只依靠仿真無法反應(yīng)在實際通信場景中環(huán)境因素對協(xié)議通信過程中的丟包率、時延等指標的影響，因此需要對AODV 協(xié)議在實際應(yīng)用中的性能進行統(tǒng)計測試[6]。

AODV[7]路由協(xié)議有多種的實現(xiàn)的版本，例如 Mad-Hoc[8]、 AODV-UCSB[9]、 AODV-UU[10]、Kernel-AODV[11]和AODV-UIUC。其中，AODV-UU協(xié)議是由瑞典烏普薩拉大學（Uppsala University）聯(lián)合愛立信公司發(fā)布的一種路由協(xié)議，是一種穩(wěn)定且開源的協(xié)議實現(xiàn)[12]。

AODV-UU 源代碼能夠在Linux-2.6[13]以及Linux-3.8 的內(nèi)核版本中實現(xiàn)，但與當前主流的Linux-4.0 以上的版本不能兼容。本文在ZYNQ-7 000平臺下，研究了將AODV-UU 協(xié)議在嵌入式Linux-4.14 內(nèi)核系統(tǒng)上實現(xiàn)的關(guān)鍵技術(shù)。

1 軟硬件平臺設(shè)計

1.1 硬件設(shè)計方案

1）PYNQ-Z2 開發(fā)板。為了方便上層應(yīng)用程序在功能擴展時需要增加外圍設(shè)備的需求，在開發(fā)板的選型上選擇了由處理系統(tǒng)（processing system，PS）以及可編程邏輯（progarmmable logic，PL）共2 部分所組成的PYNQ-Z2 開發(fā)板。PYNQZ2[14]采用的是ZYNQ-7000 系列[15]的XC7Z020-1CLG400C 型號的系統(tǒng)級芯片(system on chip，SOC)，內(nèi)部異構(gòu)了雙核ARM Cortex-A9 CPU 以及現(xiàn)場可編程門陣列(field programmable gate array，F(xiàn)PGA)，具體的實現(xiàn)過程中用到了PS 部分中的USB、SD 卡、UART 以及Eth0 等接口[16]，PYNQZ2 處理系統(tǒng)結(jié)構(gòu)如圖1 所示。

圖1 PYNQ-Z2 處理系統(tǒng)結(jié)構(gòu)

2）USB WiFi 網(wǎng)卡。網(wǎng)卡的選型需要與所工作的內(nèi)核系統(tǒng)相適配，由于Linux-4.14 的內(nèi)核系統(tǒng)可通過內(nèi)部驅(qū)動支持RT5370 型號網(wǎng)卡，所以網(wǎng)卡最終選型為支持Ad Hoc 模式的RT5370。

3）Micro SD 卡。SD 作為內(nèi)核鏡像、啟動文件、根文件系統(tǒng)以及協(xié)議可執(zhí)行文件的存放載體，因此SD 卡需要能夠進行高速的數(shù)據(jù)讀寫并且容量最小為16 GB。

1.2 軟件設(shè)計方案

方案包括了硬件電路接口設(shè)計以及Linux 系統(tǒng)定制化設(shè)計2 個部分。使用Xilinx 公司的Vivado 軟件對硬件電路接口進行設(shè)計，Petalinux集成開發(fā)工具對Linux 系統(tǒng)內(nèi)核、根文件系統(tǒng)、設(shè)備樹等完成定制化設(shè)計，避免了對各部分模塊的單獨設(shè)計與編譯。圖2 為軟件設(shè)計方案。

圖2 軟件設(shè)計方案

硬件電路接口設(shè)計中根據(jù)所需功能對PYNQZ2 開發(fā)板中的各個接口進行用戶設(shè)計。設(shè)計過程中針對開發(fā)板自身特性對PS 端的相關(guān)接口進行使能連通開發(fā)板中相關(guān)電路，對PL 端接口失能減少電路中的冗余部分，圖3 為最終的硬件電路設(shè)計圖。

圖3 ZYNQ 處理系統(tǒng)實現(xiàn)

在Linux 系統(tǒng)的定制化中對內(nèi)核系統(tǒng)、根文件系統(tǒng)以及設(shè)備樹進行用戶級設(shè)計。

1）內(nèi)核系統(tǒng)。AODV 協(xié)議在實際應(yīng)用時要在無線網(wǎng)絡(luò)的環(huán)境中利用無線網(wǎng)卡進行通信。因此在進行內(nèi)核系統(tǒng)設(shè)計時要支持IEEE 802.11 網(wǎng)絡(luò)協(xié)議棧、無線局域網(wǎng)以及與RT5370 網(wǎng)卡相關(guān)的驅(qū)動和網(wǎng)絡(luò)適配器。

2）根文件系統(tǒng)。根文件系統(tǒng)不僅能將初始化的進程從內(nèi)核態(tài)引導入用戶態(tài)中，還可以存儲AODV 協(xié)議在實現(xiàn)過程中所用到的內(nèi)核鏡像、啟動文件、網(wǎng)絡(luò)配置工具等需要永久保存的文件信息。操作系統(tǒng)默認的啟動方式是虛擬的根文件系統(tǒng)，因此需要將根文件系統(tǒng)的啟動位置改為由SD 卡啟動。

3）工程設(shè)備樹。設(shè)備樹的作用是對硬件中的外設(shè)進行驅(qū)動，設(shè)計過程中需要對開發(fā)板中的USB 接口進行驅(qū)動使得能夠正常地使用RT5370 網(wǎng)卡，驅(qū)動方式選擇了利用Petalinux 中的設(shè)備樹文件對USB 接口進行驅(qū)動。同一個設(shè)備樹文件可根據(jù)用戶需求同時驅(qū)動多個外圍設(shè)備，方便日后對外設(shè)驅(qū)動的擴展以及管理。

4）項目工程編譯。在軟件設(shè)計完成后對整個項目進行綜合編譯生成image.ub 鏡像文件并對uboot、fsbl 等文件進行打包生成BOOT.BIN 啟動文件。

2 AODV 協(xié)議實現(xiàn)

AODV-UU 是在Netfilter 功能框架的基礎(chǔ)上實現(xiàn)的，分為用戶層與內(nèi)核層2 部分。路由功能模塊和轉(zhuǎn)發(fā)數(shù)據(jù)包模塊分別在用戶層和內(nèi)核層實現(xiàn)，用戶層與內(nèi)核層之間通過Netlink socket 套接字進行數(shù)據(jù)的雙向交互，運行機制如圖4 所示。

2.1 用戶層實現(xiàn)

用戶層中的aodvd 守護進程來實現(xiàn)AODVUU 協(xié)議的路由功能模塊，路由功能模塊根據(jù)路由協(xié)議算法計算出正確的路由后通過核心應(yīng)用程序接口(application programming interface，API)來維護內(nèi)核路由表?？梢栽诒３洲D(zhuǎn)發(fā)功能模塊不變的情況下通過修改路由功能模塊來實現(xiàn)AODV協(xié)議。

本次實現(xiàn)的嵌入式平臺系統(tǒng)為Linux-4.14，生成的aodvd 可執(zhí)行文件需要在該系統(tǒng)中運行，因此將用戶層Makefile 中內(nèi)核版本的路徑改為用戶所需的內(nèi)核源碼路徑，編譯工具選擇使用交叉編譯工具，修改完成后對用戶模塊進行編譯生成aodvd 可執(zhí)行文件，修改結(jié)果如圖5 所示。

圖5 Makefile 修改后文件

2.2 內(nèi)核層實現(xiàn)

內(nèi)核層的作用是對數(shù)據(jù)包進行通信管理，在進行發(fā)送或者轉(zhuǎn)發(fā)之前會檢查內(nèi)核路由表中是否有該數(shù)據(jù)包的目的地址，有則直接發(fā)送數(shù)據(jù)，沒有則向用戶層的守護進程發(fā)起進行路由的查找請求，由守護進程發(fā)起路由查找。

內(nèi)核層中的代碼與移植的內(nèi)核版本相關(guān)，根據(jù)內(nèi)核版本的變動對內(nèi)核層中的模塊進行修改。與Linux-2.6 相比Linux-4.14 中負責用戶空間與內(nèi)核空間通信的libipq 模塊被刪除，在實現(xiàn)過程中使用隊列來替代該模塊功能，實現(xiàn)后內(nèi)核與用戶空間交互如圖6 所示。

圖6 通信交互機制

在代碼層級的實現(xiàn)過程中，最重要的改變是對netlink 套接字處理函數(shù)以及進程控制函數(shù)的改動。其中一個是使用nlmsg_put 函數(shù)來代替NLMSG_PUT 函數(shù)，該函數(shù)的作用是將發(fā)送的數(shù)據(jù)放入套接字緩沖區(qū)中。另外proc_net_create 函數(shù)被proc_create 函數(shù)代替，該函數(shù)的作用是允許AODV-UU 應(yīng)用程序訪問內(nèi)核中的路由表。最后根據(jù)內(nèi)核版本的改動，刪除和替換了相應(yīng)宏函數(shù)以及宏定義等參數(shù)，例如對RW_LOCK_UNLOCK宏函數(shù)中的實參做出了修改等。

2.3 內(nèi)核層編譯

為了更好地兼容使用Petalinux 工具生成的內(nèi)核鏡像與啟動文件，在進行內(nèi)核層模塊編譯時同樣使用Petalinux 工具對模塊進行編譯。首先在項目中創(chuàng)建1 個名稱為kaodv 的模塊。將AODVUU 中l(wèi)nx 目錄中的內(nèi)核層源文件移植到kaodv 模塊的file 文件夾中，修改kaodv.bb 文件以便將內(nèi)核層中的源文件在編譯過程中加載入該模塊中，修改結(jié)果如圖7 所示。

圖7 kaodv.bb 實現(xiàn)

進入file 文件夾中，原本AODV-UU 內(nèi)核層中的Makefile 文件與Petalinux 中動態(tài)模塊的編譯不兼容，需要對其模塊中的Makefile 文件進行重寫，重新定義導出模塊的名稱以及需要導出的測試源文件，修改完成后對新建模塊進行編譯生成kaodv.ko 動態(tài)加載模塊，文件修改結(jié)果如圖8所示。

圖8 kaodv 模塊中Makefile 實現(xiàn)

3 AODV 協(xié)議組網(wǎng)通信

3.1 WiFi 網(wǎng)卡配置

AODV 協(xié)議在實際應(yīng)用中需運行在Ad Hoc 網(wǎng)絡(luò)中，因此以節(jié)點C 為例對無線網(wǎng)卡進行以下配置：步驟1）、2）設(shè)置網(wǎng)卡模式與essid 分別為Ad Hoc 與aodv；步驟3）、4）設(shè)置網(wǎng)卡的IP 地址；步驟5）為檢測無線網(wǎng)卡能否正常工作，網(wǎng)卡具體配置步驟為：

1） iwconfig wlan0 mode ad-hoc；

2） iwconfig wlan0 essid “aodv”；

3） ifconfig wlan0 up；

4） ifconfig wlan0 192.168.6.8；

5） iwlist wlan0 scanning aodv。

3.2 連通性測試

本次測試在Ad Hoc 網(wǎng)絡(luò)中進行，其中節(jié)點A 為虛擬機，節(jié)點B 與節(jié)點C 為PYNQ-Z2 板卡。將節(jié)點設(shè)為同一局域網(wǎng)段后節(jié)點之間相互連通，此時的網(wǎng)絡(luò)拓撲結(jié)構(gòu)如圖9 所示，由圖10、11 可知3 個節(jié)點互相連通，并且TTL 為64 說明節(jié)點之間可以經(jīng)過一跳到達。

圖9 點對點單跳節(jié)點間連通

圖10 節(jié)點A 與節(jié)點B、C 連通

圖11 節(jié)點B 與節(jié)點C 連通

使用iptables 工具屏蔽節(jié)點A 與節(jié)點C 的物理地址，此時網(wǎng)絡(luò)拓撲結(jié)構(gòu)如圖12 所示，節(jié)點A 再次對節(jié)點C 發(fā)送報文，此時2 個節(jié)點無法連通，如圖13 所示。

圖12 點對點單跳節(jié)點不連通

圖13 節(jié)點A 與節(jié)點C 不連通

最后網(wǎng)絡(luò)中各節(jié)點都運行AODV 協(xié)議，首先使用insmod kaodv.ko 命令加載kaodv.ko 模塊，然后節(jié)點運行aodvd 程序，此時節(jié)點A 與節(jié)點C 會將鄰居節(jié)點B 的IP 地址加入到內(nèi)核路由表中，節(jié)點B 將鄰居節(jié)點A、C 的IP 地址加入到內(nèi)核路由表中，此時的網(wǎng)絡(luò)拓撲結(jié)構(gòu)如圖14 所示。隨后由節(jié)點A 向節(jié)點C 發(fā)送報文結(jié)果如圖15 所示，此時節(jié)點A 與節(jié)點C 再次連通并且存活時間(time to live，TTL)值變?yōu)?3，說明由節(jié)點A 經(jīng)過兩跳途經(jīng)節(jié)點B 到達節(jié)點C，使用tracepath 命令進行路由追蹤可知節(jié)點A 經(jīng)過節(jié)點B 后到達節(jié)點C，路由信息如圖16 所示，由測試結(jié)果可知AODV 協(xié)議在嵌入式Linux-4.14 系統(tǒng)中測試成功。

圖14 運行AODV 協(xié)議后拓撲結(jié)構(gòu)圖

圖15 運行aodvd 后節(jié)點A 與節(jié)點C 連通

圖16 節(jié)點A 到節(jié)點C 的路由追蹤

3.3 實際通信測試

在實際的通信測試中，通過上層應(yīng)用程序由節(jié)點C 持續(xù)不斷的向節(jié)點A 發(fā)送報文，在測試中每個時間段測試5 次取平均值得到網(wǎng)絡(luò)中的平均丟包率、平均往返時間以及平均吞吐量等性能指標。

往返時延(round-trip time，RTT)指數(shù)據(jù)包由節(jié)點C 發(fā)送數(shù)據(jù)到節(jié)點C 接收到節(jié)點A 的確認總共經(jīng)過的時延。圖17 顯示了節(jié)點之間各時間段內(nèi)的平均往返時間保持在27 ms 左右。

圖17 平均往返時間測試結(jié)果

吞吐量指節(jié)點A 在單位時間內(nèi)接收到節(jié)點C 的數(shù)據(jù)量。圖18 顯示了網(wǎng)絡(luò)中2 個節(jié)點之間各時間段內(nèi)的平均吞吐量保持在70 kb/s 附近。

圖18 平均吞吐量統(tǒng)計結(jié)果

丟包率指傳輸中所丟失數(shù)據(jù)包占所發(fā)送數(shù)據(jù)包的比率。圖19 顯示了網(wǎng)絡(luò)中各時間段內(nèi)的平均丟包率在500 s 之后逐漸趨近于0.4%。

圖19 平均丟包率統(tǒng)計結(jié)果

4 結(jié)束語

本文概述了PYNQ-Z2 平臺的軟硬件性能，介紹了Petalinux 工具在移植過程中的作用，分析了AODV-UU 協(xié)議的運行機制并以PYNQ-Z2 為例研究了AODV 協(xié)議在嵌入式Linux-4.14 系統(tǒng)上的實現(xiàn)方案，解決了AODV 協(xié)議在當前嵌入式Linux系統(tǒng)中的實際應(yīng)用問題，最后對協(xié)議在實際通信過程中的平均往返時間、平均丟包率等性能指標進行了測試，測試結(jié)果表明各性能指標良好具備實際應(yīng)用價值。