周佳琦，黃 璨2，曹建玲，任麗丹，任 智

(1.重慶郵電大學(xué) 通信與信息工程學(xué)院，重慶 400065；2.北京郵電大學(xué) 電子工程學(xué)院，北京100876)

0 引 言

節(jié)點構(gòu)成的無線自組織網(wǎng)絡(luò)，由于其靈活性，可快速在空中組成骨干網(wǎng)絡(luò)，為缺少基礎(chǔ)設(shè)施的地面提供可靠的通信，因此被廣泛應(yīng)用于各類場景[1-2]。由于無人機(Unmanned Aerial Vehicle,UAV)快速移動和能量限制等特性，網(wǎng)絡(luò)中的資源管理、協(xié)議差異性和拓?fù)涔芾淼葐栴}仍然存在不少的挑戰(zhàn)[1，3-4]。軟件定義網(wǎng)絡(luò)(Software-defined Network，SDN)作為一種新型的網(wǎng)絡(luò)架構(gòu)，將網(wǎng)絡(luò)分為數(shù)據(jù)平面和控制平面，控制平面與數(shù)據(jù)平面通過南向協(xié)議OpenFlow連接[5]，其邏輯上的集中控制和網(wǎng)絡(luò)開放可編程等特性能夠很好地解決上述問題[6-7]，因此部分學(xué)者提出了軟件定義無人機自組網(wǎng)(Software-defined Unmanned Aerial Vehicle Ad Hoc Network，SD-UANET)。

文獻(xiàn)[3]提出了一種基于SDN的UANET拓?fù)涔芾韰f(xié)議，目標(biāo)是建立和維護(hù)UANET拓?fù)浣Y(jié)構(gòu)，該文獻(xiàn)中提到在UAV節(jié)點接收到流表項缺失數(shù)據(jù)包后選擇請求控制節(jié)點處理。文獻(xiàn)[8]針對UANET高動態(tài)、不穩(wěn)定的空中無線鏈路和無人機碰撞的特性提出了SD-UANET架構(gòu)。文獻(xiàn)[9]為了保證UAV狀態(tài)信息的可靠傳輸，在控制節(jié)點收到狀態(tài)信息后向UAV節(jié)點回復(fù)一個ACK消息。文獻(xiàn)[10]中UAV節(jié)點周期性發(fā)送HELLO消息收集鄰居信息，通過AODV路由協(xié)議將鄰居信息發(fā)送給控制節(jié)點，控制節(jié)點根據(jù)收集的鄰居信息計算路由并向每個UAV節(jié)點下發(fā)路由信息。文獻(xiàn)[11]中UAV節(jié)點將更新消息和下游節(jié)點的更新消息相合并發(fā)送給控制節(jié)點，減少路由更新過程的控制開銷。文獻(xiàn)[12]為最新的OpenFlow協(xié)議標(biāo)準(zhǔn)，協(xié)議標(biāo)準(zhǔn)規(guī)定在節(jié)點緩存區(qū)足夠的情況下采用請求流表項的處理方式，在節(jié)點緩存區(qū)不足的情況下將整個數(shù)據(jù)包發(fā)送給控制節(jié)點處理。

通過以上研究發(fā)現(xiàn)，現(xiàn)有SD-UANET中針對流表項缺失數(shù)據(jù)包處理方法的研究較少且存在如下問題：一是UAV節(jié)點對于接收到的流表項缺失數(shù)據(jù)包目前采用向控制節(jié)點發(fā)請求消息或向控制節(jié)點發(fā)送流表項缺失數(shù)據(jù)包的處理方式，由于UAV節(jié)點的移動性，最短時延的轉(zhuǎn)發(fā)方式不斷發(fā)生變化，采用單一的轉(zhuǎn)發(fā)方式會帶來較大的時延；二是控制節(jié)點與UAV節(jié)點之間發(fā)送的控制包數(shù)量較多，產(chǎn)生的網(wǎng)絡(luò)控制開銷較大且無線碰撞概率較大。

為了解決現(xiàn)有文獻(xiàn)在SD-UANET路由維護(hù)方面存在的問題，本文提出了一種高效自適應(yīng)的軟件定義無人機自組網(wǎng)路由維護(hù)機制，通過估計距離自適應(yīng)選擇時延最低的轉(zhuǎn)發(fā)方式；同時提出了基于周期恢復(fù)的消息聚合策略，聚合兩類數(shù)據(jù)包減少網(wǎng)絡(luò)控制開銷，降低無線碰撞概率。

1 網(wǎng)絡(luò)場景和問題描述

1.1 網(wǎng)絡(luò)場景

SD-UANET的拓?fù)鋱D如圖1所示，由一個控制節(jié)點(Controller Node，CN)和多個UAV節(jié)點組成，UAV節(jié)點之間通過數(shù)據(jù)平面?zhèn)鬏敂?shù)據(jù)包，CN與UAV節(jié)點之間使用OpenFlow協(xié)議通信。首先,每個UAV節(jié)點周期性發(fā)送HELLO消息收集鄰居節(jié)點信息，UAV節(jié)點將收集好的鄰居信息周期性的發(fā)送給CN；然后,CN節(jié)點根據(jù)收集到的鄰居信息建立全網(wǎng)拓?fù)洳⒂嬎忝總€UAV節(jié)點的路由；最后,CN節(jié)點周期地向每個UAV節(jié)點下發(fā)流表，UAV節(jié)點根據(jù)收到的流表轉(zhuǎn)發(fā)數(shù)據(jù)包。若UAV節(jié)點收到流表項缺失數(shù)據(jù)包，則將數(shù)據(jù)包緩存，向CN發(fā)送請求流表項的消息，若UAV節(jié)點緩存空間不足，則將整個數(shù)據(jù)包發(fā)送給CN，CN根據(jù)流表信息轉(zhuǎn)發(fā)CN數(shù)據(jù)包。

圖1 SD-UANET拓?fù)鋱D

1.2 問題描述

(1)目前SD-UANET中UAV節(jié)點接收到流表項缺失數(shù)據(jù)包后處理方法有兩種：方法1采用請求CN下發(fā)流表項，由UAV轉(zhuǎn)發(fā)；方法2將數(shù)據(jù)包直接發(fā)送給CN，由CN轉(zhuǎn)發(fā)。由于UAV節(jié)點的移動性，即使UAV節(jié)點的緩存區(qū)有足夠的空間，當(dāng)方法1的轉(zhuǎn)發(fā)時延大于方法2時，單一的選擇方法1轉(zhuǎn)發(fā)會產(chǎn)生較高的時延。

(2)UAV節(jié)點不僅要周期性的上傳鄰居信息，也需要在接收到流表項缺失數(shù)據(jù)包后向控制節(jié)點發(fā)送數(shù)據(jù)包或請求流表項消息，當(dāng)兩種過程同時進(jìn)行時會增大無線傳輸?shù)呐鲎哺怕?。此外，這兩種過程都需要UAV節(jié)點向CN發(fā)送數(shù)據(jù)，相比于聚合消息發(fā)送，單獨發(fā)送數(shù)據(jù)包所產(chǎn)生的網(wǎng)絡(luò)控制開銷更大。

2 OpenFlow-EARM

針對現(xiàn)有的SD-UANET中流表項缺失處理時延長、網(wǎng)絡(luò)控制開銷大和無線傳輸碰撞問題，本文提出了OpenFlow-EARM。新機制包含如下兩個策略：一是基于距離估計的自適應(yīng)轉(zhuǎn)發(fā)策略，在UAV節(jié)點中收到流表項缺失的數(shù)據(jù)包的情況下，UAV節(jié)點通過歷史流表項信息估計目的節(jié)點的位置，再根據(jù)估計位置選擇時延最低的轉(zhuǎn)發(fā)方式；二是基于周期恢復(fù)的消息聚合策略，通過聚合鄰居信息和流表項缺失處理過程的控制包減少網(wǎng)絡(luò)控制開銷，考慮到鄰居信息是周期性上傳，流表項缺失處理過程的控制包為非周期發(fā)送，由于聚合消息產(chǎn)生后立即發(fā)送，因此在聚合消息發(fā)送后需要將鄰居信息的發(fā)送周期恢復(fù)到原周期。

2.1 基于距離估計的自適應(yīng)轉(zhuǎn)發(fā)策略

針對1.2 問題描述(1)，本文提出了基于距離估計的自適應(yīng)轉(zhuǎn)發(fā)策略，該策略核心思想是，通過流表項刪除后的時間值和UAV節(jié)點最快移動速度計算得到目的UAV的最大移動范圍，根據(jù)最大移動范圍信息計算得到UAV節(jié)點到目的節(jié)點和控制節(jié)點到目的節(jié)點的距離；然后通過以上兩個距離信息和UAV節(jié)點到控制節(jié)點的距離計算出兩種方法的時延；最后根據(jù)計算出的時延選擇最低時延的方法轉(zhuǎn)發(fā)。

2.1.1 距離估計

假設(shè)UAV的最大移動速度為vmax，流表項移除后的時間值tmove為

tmove=Tnow-Tremove。

(1)

該值等于當(dāng)前時刻與流表項移除時刻之差。假設(shè)Tnow時刻的UAV節(jié)點的位置為L(Xu,Yu)，控制節(jié)點的位置為L(Xc,Yc)，Tremove時刻目的節(jié)點的位置為L(Xd,Yd)。通過公式(2)計算得到tmove時間內(nèi)UAV的最大移動距離Dmax為

Dmax=vmax×tmove。

(2)

因此在tmove時間內(nèi)，目的UAV節(jié)點的活動范圍為以L(Xd,Yd)為中心、半徑為Dmax的圓內(nèi)，根據(jù)公式(3)計算得到圓上的坐標(biāo)位置L(Xr,Yr)為

(3)

如圖2所示，L(Xu,Yu)和L(Xc,Yc)分別與圓心L(Xd,Yd)連為一條線段并將其延伸，這兩條線段與圓上相交4個點，這4個點分別為距離UAV節(jié)點和控制節(jié)點的最遠(yuǎn)和最近坐標(biāo)點。

圖2 距離估計原理圖

根據(jù)UAV節(jié)點的通信范圍，可以得到相鄰節(jié)點之間平均距離間隔為Dinter，最后根據(jù)公式(4)計算得到距離為D的路徑上產(chǎn)生的時延d為

(4)

式中：PL為發(fā)送數(shù)據(jù)包的包長，Rtrans為發(fā)信機的發(fā)送速率，dprop、dproc和dque分別為UAV節(jié)點的傳播時延、處理時延和排隊時延。

2.1.2 基于距離估計的自適應(yīng)轉(zhuǎn)發(fā)策略具體流程

基于距離估計的自適應(yīng)轉(zhuǎn)發(fā)策略流程如圖3所示。

圖3 基于距離估計的自適應(yīng)轉(zhuǎn)發(fā)策略流程圖

基于距離估計的自適應(yīng)轉(zhuǎn)發(fā)策略的具體步驟如下：

Step1 判斷UAV節(jié)點的歷史流表項信息中是否有流表項缺失數(shù)據(jù)包匹配的流表項，若有則執(zhí)行Step 2，若沒有則執(zhí)行方法1，控制節(jié)點向UAV節(jié)點下發(fā)到目的節(jié)點的流表項。

Step2 根據(jù)公式(5)和各節(jié)點坐標(biāo)計算得到UAV節(jié)點與控制節(jié)點之間距離Duc、控制節(jié)點到目的節(jié)點最小距離Dcr1、最大距離Dcr4，UAV節(jié)點到目的節(jié)點最小距離Dur2、最大距離Dur3：

(5)

Step3 將Step 2計算出的距離代入公式(4)，計算得到方法1和方法2的最大、最小轉(zhuǎn)發(fā)時延，如公式(6)所示：

(6)

若滿足公式(7)表示方法1轉(zhuǎn)發(fā)的最大時延小于方法2轉(zhuǎn)發(fā)的最小時延，則選擇方法1轉(zhuǎn)發(fā)；若滿足公式(8)表示方法1轉(zhuǎn)發(fā)的最小時延大于方法2轉(zhuǎn)發(fā)的最大時延，則選擇方法2轉(zhuǎn)發(fā)，若都不滿足則執(zhí)行Step 4。

(dway2)min>(dway1)max，

(7)

(dway2)max<(dway1)min。

(8)

Step4 根據(jù)時刻Tremove目的節(jié)點的位置分別計算兩種方法的轉(zhuǎn)發(fā)時延，選擇時延最小的方法轉(zhuǎn)發(fā)。

2.2 基于周期恢復(fù)的消息聚合策略

針對1.2 問題描述(2)，本文提出了基于周期恢復(fù)的消息聚合策略。該策略核心思想是，通過聚合鄰居信息和流表項缺失處理過程的控制包減少網(wǎng)絡(luò)控制開銷，考慮到鄰居信息是周期性上傳，流表項缺失處理過程的控制包為非周期發(fā)送，在流表項缺失處理過程執(zhí)行后，控制包以多于一個原周期的間隔發(fā)送直到恢復(fù)到原周期。

2.2.1 Packet-in消息格式修改

本策略使用OpenFlow協(xié)議中的Packet-in消息傳輸鄰居信息、流表項缺失數(shù)據(jù)包和請求流表項消息，Packet-in消息格式如圖4所示。

圖4 Packet-in數(shù)據(jù)包結(jié)構(gòu)

在不觸發(fā)流表項缺失處理過程的情況下，UAV節(jié)點傳輸鄰居信息使用原有的Type值(Packet-in Type=10)，如果觸發(fā)了流表項缺失處理過程，則使用新定義的聚合消息：聚合消息分為鄰居信息與流表項缺失數(shù)據(jù)包聚合(Type=74)和鄰居信息與請求流表項消息聚合(Type=138)，由于聚合消息需要將鄰居信息與整個流表項缺失數(shù)據(jù)包(或128 B的字節(jié)頭[12])區(qū)分開，本策略將添加一個32 b的Position字段表示流表項缺失數(shù)據(jù)包在Data字段的位置。

2.2.2 基于周期恢復(fù)的消息聚合策略具體流程

基于周期恢復(fù)的消息聚合策略流程如圖5所示。

圖5 基于周期恢復(fù)的消息聚合策略流程圖

基于周期恢復(fù)的消息聚合策略的具體步驟如下：

Step1 UAV節(jié)點以周期T向控制節(jié)點發(fā)送鄰居信息，控制節(jié)點收到鄰居信息后向UAV節(jié)點發(fā)送ACK消息。

Step2 UAV節(jié)點判斷是否在超時時間內(nèi)收到來自于控制節(jié)點的ACK消息，若收到了則執(zhí)行Step 3，若沒有收到則執(zhí)行Step 1。

Step3 判斷是否有請求流表項消息或流表項缺失數(shù)據(jù)包需要發(fā)送，如果有則執(zhí)行Step 4，如果沒有則執(zhí)行Step 1。

Step4 聚合兩類消息，立即發(fā)送。

Step5 發(fā)送聚合消息后，判斷發(fā)送時刻是否為周期T的整數(shù)倍，如果是則執(zhí)行Step 6；如果不是則下一個鄰居信息以上整數(shù)[T]+1時刻發(fā)送，然后再次執(zhí)行Step 5。

Step6 判斷發(fā)送次數(shù)是否等于周期數(shù)，如果等于表示已經(jīng)恢復(fù)到原來的周期；如果不是則以1.5個原周期發(fā)送鄰居信息，然后再次執(zhí)行Step 6。

3 仿真驗證

本文使用OPNET14.5仿真軟件對OpenFlow-EARM機制的性能進(jìn)行驗證，在相同的網(wǎng)絡(luò)環(huán)境下，將OpenFlow-EARM機制與現(xiàn)有的最優(yōu)化鏈路狀態(tài)路由(Optimal Link State Routing,OLSR)協(xié)議和OpenFlow協(xié)議相比較。

3.1 仿真參數(shù)設(shè)置

主要的仿真參數(shù)如表1所示，仿真場景由一個控制節(jié)點和多個UAV節(jié)點組成，UAV節(jié)點均勻的分布在2 500 m×2 500 m的場景中。

表1 主要仿真參數(shù)

3.2 性能指標(biāo)

3.2.1 平均端到端時延

平均端到端時延是數(shù)據(jù)包成功地從源節(jié)點到達(dá)目的節(jié)點所花費的平均時間?？梢允褂霉?9)進(jìn)行計算:

(9)

式中：ATi是數(shù)據(jù)包到達(dá)時間，STi是數(shù)據(jù)包發(fā)送時間，n是數(shù)據(jù)包總數(shù)。

3.2.2 網(wǎng)絡(luò)控制開銷

OLSR和OpenFlow采用不同控制方式，本文對于不同控制方式網(wǎng)絡(luò)的網(wǎng)絡(luò)控制開銷統(tǒng)計方式有所不同，OLSR作為表驅(qū)動協(xié)議，其網(wǎng)絡(luò)控制開銷主要來自于路由表更新，為了與OpenFlow中的流表項缺失處理過程相對應(yīng)，本文統(tǒng)計OLSR中路由表更新和缺失路由表項處理兩個部分的網(wǎng)絡(luò)控制開銷；OpenFlow由于其控制平面和數(shù)據(jù)平面分離，流表更新過程中網(wǎng)絡(luò)控制開銷來自于UAV節(jié)點發(fā)出的HELLO消息、UAV節(jié)點上傳鄰居信息和控制節(jié)點下發(fā)流表這三個過程，與OLSR相對應(yīng)，本文統(tǒng)計OpenFlow協(xié)議中流表更新和流表項缺失處理的網(wǎng)絡(luò)控制開銷。

3.2.3 丟包率

丟包率(Packet Loss Rate,PLR)為丟失數(shù)據(jù)包數(shù)量占發(fā)送數(shù)據(jù)包數(shù)量的比率，如公式(10)所示：

(10)

式中：PT為源節(jié)點發(fā)送的數(shù)據(jù)包個數(shù)，PR為目的節(jié)點成功接收的數(shù)據(jù)包個數(shù)。

3.3 仿真分析

3.3.1 平均端到端時延

圖6所示為平均端到端時延。由圖可知，隨著節(jié)點數(shù)量的增多，平均端到端時延逐漸增大。這是因為場景中的節(jié)點數(shù)更加密集，端到端的跳數(shù)越多，場景的范圍較小，因此傳播時延對平均端到端時延的影響較少。仿真結(jié)果表明，在節(jié)點數(shù)為25時，OpenFlow與OLSR相比時延降低了2.6%，OpenFlow-EARM與OpenFlow相比時延降低了8.3%，主要原因有如下三點：一是OLSR節(jié)點在收到?jīng)]有路由表項的數(shù)據(jù)包時，節(jié)點會丟棄數(shù)據(jù)包或緩存數(shù)據(jù)包等待下一次路由表更新后再查表轉(zhuǎn)發(fā)，OLSR需要等待至少一個更新周期才能轉(zhuǎn)發(fā)數(shù)據(jù)包，因此帶來的時延較大；二是OpenFlow在節(jié)點收到?jīng)]有流表項的數(shù)據(jù)包時，采用1.2 問題描述(1)中的兩種方法，這兩種方法主動處理流表項缺失數(shù)據(jù)包，相比于OLSR的時延更低；三是OpenFlow-EARM機制采用距離估計選擇時延最低的轉(zhuǎn)發(fā)方式，相比于OpenFlow的較為單一的轉(zhuǎn)發(fā)方式，OpenFlow-EARM自適應(yīng)選擇時延最低的方式轉(zhuǎn)發(fā)，轉(zhuǎn)發(fā)流表項缺失數(shù)據(jù)包所花費的時間更短，因此平均端到端時延更短。值得注意的是，在節(jié)點數(shù)量為20時，OpenFlow-EARM相比于OpenFlow時延只降低了3.4%，這是因為距離估計會帶來一定的誤差，但是從整體來說，OpenFlow-EARM的平均端到端時延低于OpenFlow。

3.3.2 網(wǎng)絡(luò)控制開銷

圖7所示為網(wǎng)絡(luò)控制開銷。由圖可知，隨著節(jié)點數(shù)的增多網(wǎng)絡(luò)控制開銷逐漸增大。這是因為網(wǎng)絡(luò)拓?fù)浣⑦^程需要收集信息的節(jié)點數(shù)增多。在25節(jié)點情況下OpenFlow相比于OLSR控制開銷降低了49.6%，主要原因是OLSR協(xié)議由于其分布式結(jié)構(gòu)，需要每個節(jié)點收集拓?fù)湫畔⒉?gòu)建全網(wǎng)拓?fù)?，?gòu)建過程中每個節(jié)點需要發(fā)送HELLO消息建立鄰居表和MPR節(jié)點廣播TC消息，因此隨著節(jié)點的增加，網(wǎng)絡(luò)控制開銷也急劇增加；OpenFlow由于其集中式控制消除了OLSR協(xié)議所使用的泛洪，因此，使用OpenFlow減少了轉(zhuǎn)發(fā)的信息，從而減少了網(wǎng)絡(luò)控制開銷。OpenFlow-EARM將處理流表項缺失過程的控制包與UAV節(jié)點鄰居信息相聚合，雖然聚合的數(shù)據(jù)包相比于原有的Packet-in多了Position字段，但是減少了控制數(shù)據(jù)包的發(fā)送次數(shù)，Packet-in數(shù)據(jù)包包頭所帶來的控制開銷遠(yuǎn)大于Position字段，因此OpenFlow-EARM的網(wǎng)絡(luò)控制開銷比OpenFlow低，節(jié)點數(shù)為25時，相比于OpenFlow，OpenFlow-EARM控制開銷只降低了1.3%，其原因是隨著節(jié)點數(shù)的增多，相比于聚合消息減少的網(wǎng)絡(luò)控制開銷，網(wǎng)絡(luò)中出現(xiàn)節(jié)點流表項缺失的情況增多帶來的網(wǎng)絡(luò)控制開銷更大，因此節(jié)點數(shù)量越多，OpenFlow-EARM的網(wǎng)絡(luò)控制開銷越接近OpenFlow的網(wǎng)絡(luò)控制開銷。

圖7 網(wǎng)絡(luò)控制開銷

3.3.3 丟包率

圖8所示為丟包率。由圖可知，隨著節(jié)點數(shù)量的增加，丟包率逐漸增大。這是因為節(jié)點數(shù)量增多，導(dǎo)致數(shù)據(jù)消息和控制消息發(fā)送的數(shù)量增多，從而導(dǎo)致無線信道中碰撞概率的增大。節(jié)點數(shù)為25時，OpenFlow相比于OLSR丟包率降低了6.4%，其原因是OLSR在數(shù)據(jù)包沒有路由的情況下，UAV節(jié)點會將數(shù)據(jù)包直接丟棄或者等待下一次的更新，然而OpenFlow中數(shù)據(jù)包沒有匹配的流表項會立即向控制節(jié)點報告，因此OpenFlow這種主動式的處理過程減少了丟包的概率。節(jié)點數(shù)為25時，OpenFlow-EARM相比于OpenFlow丟包率降低了2.1%，其原因是鄰居信息上傳和流表項缺失處理過程是同時進(jìn)行的，由于OpenFlow-EARM機制采用了消息聚合的方式，降低了兩種過程所產(chǎn)生的無線碰撞的概率，因此OpenFlow-EARM的丟包率低于OpenFlow。

圖8 丟包率

4 結(jié)束語

本文針對目前SD-UANET中流表項缺失處理過程中轉(zhuǎn)發(fā)數(shù)據(jù)包時延高、網(wǎng)絡(luò)控制開銷大和無線碰撞的問題，提出了OpenFlow-EARM機制。新機制根據(jù)刪除流表項的時刻值和UAV節(jié)點最大移動速度估算兩種轉(zhuǎn)發(fā)流表項缺失數(shù)據(jù)包所需要的時延，以此來選擇時延最低的轉(zhuǎn)發(fā)方式，降低了傳輸數(shù)據(jù)包的時延，并且在處理流表項缺失的過程中利用消息聚合的方法減少數(shù)據(jù)包的發(fā)送次數(shù)，從而減少網(wǎng)絡(luò)控制開銷，然后利用一種周期恢復(fù)的策略將鄰居信息上傳的數(shù)據(jù)包的發(fā)送間隔恢復(fù)到原周期。仿真結(jié)果表明，OpenFlow-EARM機制在平均端到端時延、網(wǎng)絡(luò)控制開銷和丟包率等方面優(yōu)于對比的協(xié)議。未來的工作將深入研究控制節(jié)點與UAV節(jié)點之間的控制消息傳輸問題。