阮文靈,曾培峰
(東華大學 計算機科學與技術學院,上海 201620)
摘要:詳細介紹了無線傳感網絡中的RPL(IPv6 Routing Protocol for LowPower and Lossy Networks)路由協議,從仿真環境、參數設定、仿真場景設計等方面對RPL路由協議的仿真進行了分析。利用cooja模擬器對RPL路由協議進行了仿真,并針對分組遞交率和平均功耗兩個性能指標對RPL路由協議進行性能評估。仿真結果表明,RPL路由協議在分組遞交率方面適用于各個場景,并能很好地適應網絡的動態變化;在功耗方面不適用于樹型空間位置的場景,并且對于動態變化的網絡會大大增加平均功耗。
關鍵詞:RPL路由協議;網絡仿真;cooja模擬器;分組遞交率;平均功耗
中圖分類號:TP391.9文獻標識碼:ADOI: 10.19358/j.issn.1674 7720.2017.03.019
引用格式:阮文靈,曾培峰.無線傳感網絡中RPL路由協議研究及性能分析[J].微型機與應用,2017,36(3):63-66.
0引言
隨著網絡的發展,物聯網[1]已經成為繼互聯網之后的發展趨勢。作為物聯網的重要組成部分,無線傳感網絡由于受到處理能力、內存容量、電量等限制,其路由協議設計充滿挑戰。互聯網工程任務組(Internet Engineering Task Force, IETF)建立低功耗有損網絡路由工作組(Routing over Lossy and Lowpower Networks, ROLL)來解決這一問題,提出一種新的路由協議RPL,即IPv6 Routing Protocol for LowPower and Lossy Networks[2]。
本文首先介紹了RPL路由協議的原理,分析了控制路由報文發送頻率的Trickle算法[3],其次用cooja[4]對不同場景進行了仿真,并根據仿真結果分析了RPL路由協議的性能,接著驗證了Trickle算法,最后進行了總結。
1RPL路由協議原理
RPL路由協議是一種距離矢量路由協議,它根據目標函數(Objective Function,OF)構建以目的節點(根節點)為導向的有向無環圖(DestinationOriented Directed Acyclic Graph,DODAG)。每個非根節點通過目標函數計算出一個Rank值,表明自己與根節點之間的距離關系。目前常用的目標函數有OF0(Objective Function Zero)[5]、MRHOF(The Minimum Rank with Hysteresis Objective Function)[6]和ETX(Expected Transmission Count)[7]。三種控制報文用于RPL路由協議,分別是DODAG信息請求報文(DODAG Information Solicitation,DIS)、DODAG信息對象報文(DODAG Information Object,DIO)和目的廣告對象報文(Destination Advertisement Object,DAO)。DIS報文用于未加入網絡的節點向網絡中的節點主動尋求DIO報文,并尋求加入網絡;DIO報文攜帶了一些配置參數,如RPLInstanceID、DODAGID、Rank等,讓未加入網絡的節點能夠發現RPL實例并學習這些配置參數,選擇父節點,主要用于向上路由的建立;DAO報文攜帶一些路由前綴信息,主要用于向下路由的建立。
1.1DODAG構建過程
整個DODAG的構建可以分為兩個部分,第一部分是向上路由的構建,第二部分是向下路由的構建。
如圖1所示,向上路由的構建過程從根節點(6LoWPAN Border Router,6LBR)開始,6LBR廣播DIO報文,它攜帶著自己節點的信息RPLInstanceID、DODAGID、Rank等,在它傳輸范圍內的6LRA(6LoWPAN Router A)收到該DIO報文后,選擇6LBR作為父節點并加入該DODAG。6LRA具有路由功能,它會根據目標函數計算rank值并更新收到的DIO報文,并廣播出去,在它傳輸范圍內的6LRB收到該DIO報文后,選擇6LRA作為父節點并加入該DODAG。在6LRB加入DODAG后的某一時刻,6LN(6LoWPAN NODE)主動廣播DIS報文,尋求加入某個DODAG。6LRB收到該DIS報文后,給6LN回復DIO報文,讓6LN選擇6LRB作為父節點并加入DODAG。至此整個DODAG的向上路由就建立了。向下路由通過DAO報文來構建。6LRA在收到6LBR的DIO報文后,回復6LBR DAO報文,6LBR收到后將6LRA的前綴信息加入到路由表項中。6LRB收到6LRA的DIO報文后,回復6LRA DAO報文,6LRA處理該DAO報文后并向自己的父節點6LBR回復DAO報文,6LBR收到該DAO報文后將6LRB的前綴信息加入路由表項中。因此,DAO報文的處理工程是從子節點發送自己的父節點,父節點在處理后依次發送給自己的父節點,直到發送到根節點為止,根節點包含了所有節點的前綴信息。
1.2Trickle算法
Trickle算法是RPL路由協議中一個重要的組成部分,它用來控制DIO報文的發送頻率。Trickle算法運用了自適應傳輸周期機制,保證網絡中路由信息一致時,發送較少的路由報文;而不一致時迅速發送大量的路由報文,從而快速更新路由信息,保證一致性。
為了實現上述自適應傳輸周期的機制,Trickle算法使用了3個配置參數:最小時隙Imin表示DIO報文發送間隔的最小范圍;最大時隙Imax表示DIO報文發送間隔的最大范圍;常數k用于表征DIO報文是否發送。Trickle算法還使用了3個變量:當前時隙I,表示DIO報文當前的發送間隔;當前時隙的時間點t,表示只有到達當前時隙中的時間點t,DIO報文才有可能發送;一致性計數器c,用于與常數k比較,根據比較結果決定是否發送DIO報文。
Trickle算法的具體執行步驟如下:
(1)Trickle算法開始執行時,首先把當前時隙I隨機置成[Imin, Imax]中的一個時隙,并且開始第一個時隙;
(2)當一個時隙開始時,把一致性計數器c重置成0,并把時間點t設為當前時隙I中大于等于I/2、小于等于I的一個隨機時間點;
(3)當監聽到一致性消息時,增加計數器c;
(4)在時間點t,當計數器c小于常數k時,發送DIO消息,否則不發送DIO消息;
(5)當時隙I過期后,時隙I=I×2,當I>Imax時, I置成Imax,并判斷下一時隙是否有效,若有效返回步驟(2),否則結束;
(6)當監聽到不一致性消息并且I>Imin時,重置I為Imin,當I=Imin時,什么也不做,并判斷下一時隙是否有效,若有效返回步驟(2),否則結束。
2仿真環境和參數設置
2.1仿真環境
使用cooja對RPL路由協議進行仿真,cooja是基于Contiki操作系統[8]的模擬器。
2.2仿真參數
在仿真實驗中,使用的目標函數為ETX(Expected Transmission Count)。ETX指一個節點成功傳輸一個數據包給目的節點需要傳輸的次數。無線介質類型是UDMG類型,如圖2所示,內部的圓區域代表了節點1能從其他節點接收包的范圍,其中的百分比分別代表了從不同節點接收包的成功率,它隨著與節點1的距離增大而減小。外部的圓區域為受到無線干擾的范圍。設置接收包的范圍為50 m,受到干擾的范圍是100 m,發送包的成功率為100%,接收包的成功率根據節點間的距離確定。
仿真時間為15 min,節點的類型為sky類型,并且只有1個根節點。在不同空間位置關系的節點圖仿真實驗中,有30個具有路由功能的節點;在動態增減節點的仿真實驗中,在第5 min時動態減少或增加10個有路由功能的節點。這些節點分布在200 m×200 m的正方形區域內。
3仿真分析
為了對仿真結果進行分析,需要使用評估RPL路由協議的性能指標[9],使用分組遞交率和平均功耗作為評估的指標。
3.1不同空間位置關系的節點圖仿真
為了評估RPL路由協議在不同的拓撲情況下的性能,根據根節點與路由節點的關系,設計了4種不同空間位置關系的節點圖,如圖3所示。
圖4顯示了15 min內不同場景下發送給根節點包的數量和根節點接收包的數量,圖5根據圖4的數據計算出了分組遞交率。根據圖4,不同空間位置節點圖發送給根節點的包的總數基本相同,為420左右。根據圖5,格子型的分組遞交率最高,為98.81%,而樹型的分組遞交率最低,為95.44%,但是相差都不是特別大,并且包的遞交率都達到了95%以上。根據上述結果,在分組遞交率方面RPL路由協議在靜態的不同場景下都有較好的表現。
圖6顯示了15 min內除根節點之外的其他所有節點的功耗的平均值。根據圖6,樹型的平均功耗最大,為3.14 mW,格子型的平均功耗最小,為1.79 mW。樹型的平均功耗遠遠大于其他三種情況下的平均功耗。根據上述結果,在平均功耗方面PRL路由協議對于樹型位置關系表現得并不是很好,而其他三種場景下有較好的表現。
3.2動態增減節點的仿真
為了評估RPL路由協議在動態變化拓撲中的性能,設計了動態增減節點的場景。節點隨機關系的場景是最常見的場景,因此動態增減節點的仿真使用隨機關系場景。
圖7顯示了15 min內不同條件下發送給根節點包的數量和根節點接收包的數量,圖8根據圖7的數據計算出了分組遞交率。根據圖7,在第5 min時動態加入節點的場景下,其他路由節點發送給根節點和根節點接收包的數量都比原來的要多,而動態減少節點的情況下都比原來的要少;但都少于一開始靜態相同位置相同數目節點的場景,說明節點個數影響發送給根節點和根節點接收包的數量。根據圖8,在第5 min時動態加入和減少節點的場景
圖8分組遞交率與靜態相同位置相同數目節點場景相比,包遞交率相差不大,說明動態增減節點對包遞交率影響很小,RPL路由協議能夠很好地適應網絡的動態變化。
圖9顯示了15 min內不同場景的平均功耗。根據圖9,在第5 min時動態加入和減少節點的場景與靜態相同位置相同數目節點場景相比,平均功耗都大大增加,說明了在功耗方面,RPL路由協議對于動態變化的網絡會大大增加節點的平均功耗。
3.3Trickle算法的仿真
為了驗證Trickle算法能夠有效控制DIO報文的發送頻率,在網絡維持不變時增大DIO報文的發送間隔,在網絡發送變化時能夠迅速減小DIO報文發送的間隔,從而維護網絡。使用圖2進行了仿真,圖10顯示了仿真結果。
圖中橫坐標代表時間節點,縱坐標代表時隙的大小。圖中顯示了三個階段,第一階段網絡沒有發生變化,因此每次當前時隙I到期后,I變成了I×2(I×2<Imax),而當I等于Imax時,I到期后,I維持不變,圖中Imax為2 100 s,因此I到達2 100 s后一直維持不變。在第二階段移動節點6,網絡發生變化,因此Trickle算法將當前時隙I由2 100 s迅速降到最小,之后在第三階段網絡達到穩定后,節點6的時隙I仍然按照原來增長。4結束語
本文對RPL路由協議進行了詳細的介紹,并對靜態場景及動態增減節點情況下的RPL路由協議性能進行了深入評估。從仿真結果得出以下結論:
(1)對于不同靜態場景,分組遞交率都在95%以上,并且相差不大,RPL路由協議對各種節點布局都適用;對于動態增減節點,分組遞交率與靜態相比相差不大,RPL路由協議能適應網絡的動態變化。
(2)對于不同靜態場景,樹型位置關系的平均功耗遠大于其他關系的平均功耗,RPL路由協議對于樹型位置關系并不特別合適;對于動態增減節點,RPL路由協議會大大增加平均功耗。
(3)Trickle算法能夠有效地控制路由報文的發送。
參考文獻
[1] GUBBI J, BUYYA R, MARUSIC S, et al. Internet of Things (IoT): a vision, architectural elements, and future directions[J]. Future Generation Computer Systems, 2013, 29(7):1645-1660.
[2] WINTER T, THUBERT P, BRANDT A, et al. RPL: IPv6 routing protocol for lowpower and lossy networks[S]. Internet: RFC 6550, 2012.
[3] LEVIS P, CLAUSEN T, HUI J, et al. The trickle algorithm[S]. Internet: RFC 6206, 2011.
[4] OSTERLIND F, DUNKELS A, ERIKSSON J, et al. Crosslevel sensor network simulation with COOJA[C]. Proceedings of 31st IEEE Conference on Local Computer Networks, Tampa,FL: IEEE, 2006: 641-648.
[5] THUBERT P. RPL objective function zero[S]. Internet: RFC 6552, 2012.
[6] GNAWALI O, LEVIS P. The minimum rank with hysteresis objective function[S]. Internet: RFC 6719, 2012.
[7] GNAWALI O, LEVIS P. The ETX objective function for RPL[S]. Internet: draftgnawalirolletxof00, 2010.
[8] DUNKELS A, GRONVALL B, VOIGT T. Contiki a lightweight and flexible operating system for tiny networked sensors[C]. Proceedings of the 29th Annual IEEE International Conference on Local Computer Networks, 2004. IEEE, 2004:455-462.
[9] TRIPATHI J, DE OLIVEIRA J, VASSEUR J P. Performance evaluation of routing protocol for low power and lossy networks[S]. Internet: RFC 6687, 2012.