劉仕杰,董超,朱小軍,劉青昕,張磊
(1.南京航空航天大學電子信息工程學院,江蘇 南京 211106;2.南京航空航天大學計算機科學與技術學院,江蘇 南京 211106)
隨著通信技術的發展,無線用頻設備不斷增多,為了加強電磁頻譜管理和維護電磁頻譜安全[1-2],國家有關部門利用監測設備對電磁頻譜進行了全方位地監控和管理。傳統的頻譜監測設備一般位于地面,如地面監測車、監測站,頻譜監測結果易受障礙物遮擋、環境限制、多徑效應干擾等不利因素影響[3]。近年來,無人機憑借其成本低廉、易于部署、機動性強等特點在危險偏遠且成本較高的場景中受到廣泛的歡迎,并在軍事和民用領域得到越來越多的應用[1,4-5]。因此,多個軍用、民用場景采用了無人機搭載頻譜監測裝置,從空中進行頻譜監測,提高頻譜監測的機動性和效率[2]。
為了得到某一地區無線設備的用頻信息,將頻譜監測設備裝載在無人機上作為一個節點執行頻譜監測任務。多架無人機部署在所監測區域的上方形成多個節點同時進行監測,每個節點都采集數據,采集數據的速度恒定。節點需將采集的頻譜數據實時回傳至地面站,地面站作為收集各節點所采集頻譜數據的終端節點,對數據進行分析和處理。
無人機將采集的監測數據回傳至地面站時,當無人機距離地面站較近時傳輸相對容易,而當距離較遠時傳輸比較困難。可以采用蜂窩網絡的方式進行數據傳輸,比如4G 網絡。但是在實踐中發現,采用此方案時,地面站需要具有公網IP。同時,由于4G 網絡分配的IP 是私有地址,地面終端無法向無人機發送控制及反饋信息,無人機也無法將采集的頻譜數據發送到地面站。
此外,還可以采用自組織網絡的形式對數據進行傳輸,學者們對自組織網絡中的路由協議進行了深入研究。文獻[6]中通過部署一個移動機器人沿著預定的路徑移動,在這條路徑上放置三個固定節點,對BATMAN、OLSR、AODV 和DSR 的平均重路由時間和丟包率進行了評估。文獻[7]利用BATMAN、OLSR 和Babel 搭建了一個包含8 個固定無線節點的室內試驗臺,在該實驗臺上評估了吞吐量、收斂時間、分組投遞率和往返時延。文獻[8]設計了一個有三個節點的網絡,即一個地面固定目的地、一個飛行無人機源節點和一個飛行無人機中繼,從數據報丟失率方面評估了OLSR 和OLSR 的改進版本(P-OLSR)。文獻[9-13]對BATMAN-Adv 路由協議在網絡的連通性、丟包、時延、抖動、吞吐量等方面的性能進行了全面評估。自組織網絡在數據傳輸方面得到了廣泛的研究與應用。
本文針對無人機遠距離監測得到的頻譜數據如何將其回傳到地面站進行處理和分析這一問題,提出了兩種回傳方法:基于蜂窩網絡的回傳方法和基于自組織網絡的回傳方法。基于蜂窩網絡的回傳方法采用4G 蜂窩網絡,將無人機采集到的頻譜數據通過移動4G 回傳到地面站;基于自組織網絡的回傳方法將無人機和地面站形成一個自組織網絡,數據在自組網中以多跳的形式從無人機回傳到地面站。下面針對這兩種回傳方法,對其結果進行了對比和分析。
在正常區域網絡狀況良好的情況下,對于頻譜數據的回傳,可以采用基于蜂窩網絡的回傳方法,如圖1 所示,將無人機采集到的頻譜數據通過蜂窩網絡回傳到地面站。那么地面站必須得有公網IP 地址,否則無人機無法準確無誤地將數據發送到地面站。對于處于局域網內部沒有公網IP 的地面站,需要進行內網穿透[14],將地面站映射到具有公網IP 設備的某一端口上,此時執行頻譜采集任務的無人機只需將數據發往此具有公網IP 設備的端口上,即可將數據回傳到地面站。

圖1 基于蜂窩網絡的回傳方法
處于內網的地面站無法暴露到互聯網中,內網服務由于沒有公網IP,不能被非局域網內的其他用戶訪問。當使用蜂窩網絡進行數據回傳時,無人機無法正確識別出地面站的地址,給數據回傳帶來了困難。如果能將地面站暴露到互聯網中,無人機就能直接訪問地面站,實現頻譜數據的回傳。
首先,需要找到一個具有公網IP 的設備,云服務器作為一種簡單高效、安全可靠、處理能力可彈性伸縮的計算服務,是一個不錯的選擇。其次,對于云服務器上多個可使用的端口,如果能將其映射到內網中的主機,那么發往云服務器此端口的數據就能被準確無誤地轉發到內網中的此主機中。因此,需要實現一種專注于內網穿透的高性能的反向代理應用,整體呈現出C/S 架構,如圖2 所示。云服務器為服務端,需要進行內網穿透的主機為客戶端。服務端通過socket 與客戶端相連,將服務器的某個端口映射到內網主機上,然后根據請求的云服務器端口或其他信息將請求路由到對應的內網主機,將內網服務以安全、便捷的方式通過具有公網IP 節點的中轉暴露到公網,從而實現通過外網能直接訪問到內網主機,達到內網穿透的目的。針對這一思想,可以選用多種現有工具實現這一功能,比如frp[15]。

圖2 內網穿透架構圖
為此,在具有公網IP 的云服務器上部署服務端,在地面站上部署客戶端,這樣就將地面站上的某一本地端口映射到云服務器的某一端口上,此時無人機向云服務器的這一端口上發送采集到的頻譜數據,即可成功回傳到地面站中。
由于在所監測的區域上方有多架無人機執行頻譜數據采集任務,如果多架無人機都向云服務器的一個端口發送數據,那么極有可能由于數據量過大而導致服務崩潰。因此,計劃在地面站上執行多個內網穿透服務。將地面站的多個本地端口一一映射到云服務器的不同端口上,多個無人機分別向云服務器的不同端口上發送數據,即為向地面站的不同端口回傳所采集到的頻譜數據,解決了多架無人機同時向同一端口發送數據造成流量激增而可能導致服務崩潰的問題。
基于蜂窩網絡的回傳方法,無人機采集的頻譜數據需要由云服務器中轉到地面站,因此云服務器的帶寬及同時進行頻譜任務的節點數決定了每個節點回傳數據的最大速率。如圖3 所示,若云服務器的帶寬為1 Mbps,有五架無人機同時進行頻譜采集任務,那么每架無人機所能回傳數據的最大速率約為200 kbps。當任務需求需要進一步擴大無人機覆蓋范圍、需要投入更多的無人機節點時,由于云服務器的帶寬一定,隨著無人機節點數目的增多,每個節點所能回傳數據的速率也將降低,這也就降低了頻譜數據采集的效率。

圖3 基于蜂窩網絡的回傳方法瓶頸
另外,用蜂窩網絡進行數據回傳成本較高。首先需要在云服務器端部署內網穿透服務端,此外在地面站和無人機上部署內網穿透客戶端需要4G 網卡的支持,租賃滿足服務要求的帶寬的云服務器和購買一定數量的4G 網卡需要一定的費用。再者,節點上傳數據的速率還與基站信號強度有關,當處于戰場、災后現場、野外等地區時,基站信號強度微弱甚至沒有信號,這時基于蜂窩網絡的回傳方法將失效。
偏遠、受災地區或戰場等地基礎設施缺乏或遭到破壞,失去了良好的通信條件。此時蜂窩網絡無法使用,數據傳輸采用基于自組織網絡的回傳方法,如圖4 所示。無人機自組網[16-18]不依賴基礎設施,支持動態拓撲和節點的任意移動,不需要一個集中的控制基站。路由協議是自組織網絡中不可缺少的一部分,主要分為反應式路由協議(如AODV)和主動式路由協議(如BATMAN-Adv、OLSR 等)。對于反應式路由協議,只有當網絡中產生流量時才會形成路由路徑,因此其網絡開銷較低,但同時也帶來了較高的時延。對于主動式路由協議,不管網絡中是否有流量的產生,都會形成路由路徑,因此需要較高的維護開銷,但會有較低的時延[19]。對于拓撲快速變化的無人機自組網,決定采用主動式路由協議將無人機采集的頻譜數據回傳到地面站。

圖4 基于自組織網絡的回傳方法
當無人機節點過多或在戰場、野外等4G 信號質量較差的區域時,使用蜂窩網絡進行數據回傳,無論是從成本考慮還是從頻譜數據采集的效率來看,都不是一個明智的選擇。因此不依賴基礎設施的自組織網絡成為了更好的選擇方案,將無人機節點和地面站配置在同一個自組織網絡中,節點采集的頻譜數據以多跳的形式回傳到地面站中。
無人機可攜帶輕型的嵌入式設備,因此在硬件選型上選用樹莓派4B 作為機載計算機。樹莓派4B 體積小、功耗低、成本低,適合裝載在無人機上。樹莓派4B 內置支持2.4 GHz 和5 GHz 信道的無線網卡,可作為系統的物理層和MAC 層實現。每臺樹莓派的網卡被配置為工作在IBSS 模式(或Ad Hoc 模式),由此將所有無人機節點和地面站配置在同一個自組網中。對于路由協議的選擇,如上所述,選擇主動式路由協議BATMAN-adv。
BATMAN_Adv(Better Approach To Mobile Ad Hoc Networking Advanced)[20]源自于對BATMAN(Better Approach To Mobile Ad Hoc Networking)路由協議的增強和改進,其理念是在以太網層(即ISO/OSI 模型的第二層)上實現路由,這導致使用虛擬網絡接口和MAC 地址來替代使用UDP 數據包實現的路由表。BATMAN_Adv 已經成為現在主要使用的BATMAN 版本,并且是在第2 層完全工作的路由協議之一。由于它是在以太網層實現的,這里的網絡就好像每個節點都有一個直接的單跳連接到另一個節點一樣,因此,數據包使用原始的以太網幀發送,直到它到達目的地。它與OLSR 等其他主動式路由協議不同,每個節點無需知道全網的網絡拓撲來獲得到達目的節點的路徑,只需要知道通過哪些鄰居節點能到達目的地,并從中選出一個最佳的鄰居節點作為數據傳輸的下一跳。這樣就使得協議輕量化,減少了每個節點要處理的數據量,從而解決了OLSR 等之前的主動式路由算法在網絡規模擴大時對節點處理能力要求增加、處理時延增大的問題。
在BATMAN_Adv 中,一個重要的概念叫做TQ(Transmission Quality),TQ 值的高低代表了鏈路傳輸質量的好壞。網絡中節點周期性地傳播OGM(Originator Message)幀,鄰居節點通過對接收到的OGM 幀進行統計和分析后,計算得到鏈路的TQ 值。每個節點針對每一個鄰居節點維護一個TQ 值,節點從鄰居節點中獲得到達目的節點的TQ 值后,從中選取TQ 值最大的節點作為數據傳輸的下一跳,也就是到達目的節點的最佳下一跳節點。
雖然當節點數目過多或處于野外、戰場區域時,基于自組織網絡的回傳方案成為替代基于蜂窩網絡的回傳方案的不二選擇,但也存在一定的缺點。由于無線網卡及芯片等其他因素的限制,自組網中可使用的帶寬有限。另外,由于無線環境的不穩定性,鏈路不穩定的情況時有發生,數據傳輸的速率波動較大,由此導致的后果是網絡中可能出現丟包、數據丟失,從而對后續數據的分析造成影響。
將樹莓派和頻譜采集設備裝載在無人機上作為頻譜采集客戶端,在地面站上進行內網穿透作為服務端接收頻譜采集數據。每臺樹莓派計算機都運行Raspberry Pi 操作系統,Linux內核版本為5.10.17。為了測量數據傳輸的吞吐量以及時延,在樹莓派上編寫java 程序,在客戶端與服務端建立TCP/UDP Socket 進行數據傳輸,并對所傳輸的數據進行統計與分析。
(1)吞吐量分析
針對不同個數的采樣節點,對每個采樣節點回傳數據的吞吐量進行統計和分析,并對各個節點的吞吐量取平均值。實驗中,樹莓派外接無線4G 網卡已連接到互聯網,連接示意圖如圖5 所示,采用的云服務器帶寬為8 Mbps。實驗結果如圖6、圖7 所示。

圖5 樹莓派外接無線4G網卡

圖6 基于蜂窩網絡回傳時節點的平均吞吐量

圖7 基于蜂窩網絡回傳總采集節點個數為5時各節點的吞吐量
從圖6 可以看出,節點的平均吞吐量與采樣的節點數之間呈現出反比的關系。當只有一架無人機節點進行頻譜收集任務時,其所能回傳數據的速率與云服務器帶寬基本保持一致。隨著采集節點數目的增多,每個無人機可用的帶寬不斷減小。由此可以預見的是,當無人機采集節點數目增大到一定程度時,其向地面站回傳數據的速率將達不到頻譜數據收集的速率,因此會導致數據積壓在本地,無法及時地將數據回傳到地面站進行處理和分析。
從圖7 可以看出,當總采集節點個數為5 時,各節點間的吞吐量分布較為穩定,沒有出現較大的差異,且基本等于云服務器帶寬的1/n,其中n為同時進行頻譜采集任務節點的個數。可以看出,基于蜂窩網絡回傳的方案穩定性較強。
(2)時延分析
為了更好地了解網絡狀況,對數據從無人機發送到地面站的時間進行了統計和分析。由于發送端與接收端時鐘不一致,因此統計的是往返時延,將發送時間封裝在數據包中,當數據包從無人機發送到地面站后,地面站立刻將此數據包回送到無人機,記錄此數據包由地面站回送到無人機的時間,計算得出數據包的往返時延。實驗中一次發送10 個數據包,對每個數據包的往返時延進行統計與分析,實驗進行多次取平均值,實驗結果如圖8 所示。

圖8 基于蜂窩網絡回傳時數據包的往返時延
從實驗結果可以看到,基于蜂窩網絡回傳的方案網絡狀況較好,網絡穩定性較高。各個數據包的往返時延較低,且比較穩定,在60 ms 附近上下小幅浮動,沒有出現較大的波動。
在自組網模式下,樹莓派無線網卡被配置為在IBSS 模式(或Ad Hoc 模式)下工作,路由協議選擇BATMAN-Adv,版本號為2020.4。MAC 層協議選擇802.11,無線信道設置為channel 8,頻率為2.447 GHz,發送功率為31.0 dBm。實驗拓撲及真實場景圖如圖9 所示,節點3、4、5 作為源節點同時進行頻譜數據的采集,節點2 作為潛在的中繼節點,節點1 作為終端節點對所采集的頻譜數據進行收集。橫向及縱向相鄰無人機間距為20 m,飛行高度為10 m。

圖9 網絡拓撲及真實場景圖
為了對實驗數據進行統計,采用iperf3[21]——一個使用較為廣泛的網絡測量工具。但是,iperf3 用于在客戶端(發送方)和服務器(接收方)之間持續發送數據流,它不能測量多對一的通信。為此,在服務器的不同端口上同時運行多個iperf 服務器進程,并讓客戶端連接到不同的服務器進程,接收來自不同節點的頻譜數據。
(1)吞吐量分析
客戶端節點3、4、5 分別以TCP 連接到服務端節點1 進行吞吐量的測試,每次測量時間為15 s,實驗進行多次取平均值,iperf3 報告結果如圖10 所示。

圖10 基于自組織網絡回傳時節點的路由表和吞吐量
從圖中可以看出,各節點間吞吐量差異顯著。節點4的吞吐量達到了8.24 Mbps,而節點5 僅為0.1 Mbps。通過查看路由表發現,節點4 的數據的路由為4-1,節點3的數據的路由為3-4-1,節點5 的數據的路由為5-4-1。也就是說,節點3 和5 到達節點1 的數據比節點4 到達節點1 的數據多了一跳,且節點4 到達節點1 的TQ 值比節點3和5 的顯著提高,因此多跳降低了路由協議的性能。而都是兩跳的節點3 和5 吞吐量差距也較大,實驗發現節點3到節點1 和節點5 到節點1 的TQ 值分別是132 和66。TQ值在一定程度上可反應出丟包率的大小,TQ 值越大,丟包率越小。由于節點5 發往節點1 的數據丟包較為嚴重,導致其吞吐量顯著低于節點3 的吞吐量。
(2)時延分析
客戶端節點3、4、5 分別以UDP 連接到服務端節點1進行時延的測試。由于iperf3 不報告時延,因此仍采用上述java 程序使用UDP 數據包測量往返時延,節點3、4、5 同時向節點1 發送數據包,對每個數據包的往返時延進行統計與分析,實驗進行多次取平均值。實驗結果如圖11 所示:

圖11 基于自組織網絡回傳時節點的往返時延
從圖中可以看出,基于自組織網絡的回傳方案時延較低,最低的往返時延以毫秒為單位并達到了個位數級別,最高的往返時延也僅為10 ms。由此可見,此方案用于數據的傳輸延遲較低,實時性較強。
當無人機距地面站超過數據鏈路的傳輸距離時,為了將無人機執行頻譜監測任務時采集的數據回傳至地面站,提出了兩種方案:一種是基于蜂窩網絡傳輸,此方案各節點的吞吐量較為穩定,不易受到外界環境的影響,但其大小受到同時進行采集節點的數目及云服務器帶寬大小的影響,適用于蜂窩信號強且存在高帶寬云服務器的場景,成本較高;另一種是基于自組織網絡進行傳輸,此方案波動較大,各節點吞吐量大小差異顯著,容易受到無線環境的干擾,但其時延較低,適用于對實時性較高的場景,成本較低。在未來的工作中,可考慮將兩種方案進行結合來傳輸數據。