面向船舶自組網的Semi-TCP研究

周 亮,姜勝明,熊晨霖

(1.上海海事大學 信息工程學院,上海 201306; 2.上海市教育考試院 網絡信息中心,上海 200433;3.華南理工大學 電子與信息學院,廣州 510641)

0 概述

傳輸控制協議(Transmission Control Protocol,TCP)在陸地互聯網上表現出良好的性能,但將其應用于船舶自組網中,其性能顯著下降。傳統TCP協議總是認為數據包的丟失是由于網絡擁塞造成的,而在船舶無線自組織網絡中,由于信道損耗、動態路由等問題,很容易造成丟包,而這種丟包并不是由于擁塞引起的。當TCP應用于無線自組織網絡中時,這種非擁塞的丟包就會造成TCP丟包即擁塞的誤判,而降低發送速率。最終造成:非擁塞時信道資源的浪費;擁塞時不利于快速解除擁塞。針對上述問題,研究者提出了多種針對無線自組網的TCP改進方案[1-2]。但大多數改進都是基于原TCP協議結構進行的,其擁塞控制[3]功能仍在傳輸層實現[4],只是在特定的環境或應用中體現出某一方面的優越性,而整體性能卻并不令人滿意,如移動自組網傳輸協議(Ad-hoc Transport Protocol,ATP)[5-6]、頻率自適應傳輸控制協議(TCP with Adaptive Pacing,TCP-AP)[7]等。

Semi-TCP是對TCP協議體系的突破,其將原傳輸層中的擁塞控制功能下放到數據鏈路層[8],通過逐跳控制,能更準確地判斷網絡擁塞狀況,提高擁塞控制效率。船舶自組網有節點密度小、單跳距離遠、信道損耗大、節點移動速度相對穩定等特點。本文結合船舶自組網的特點,對基于數據請求發送/清除發送(Request To Send/Clear To Send,RTS/CTS)的擁塞控制方法進行改進,從而提高TCP在船舶自組網中的傳輸性能。

1 相關算法

1.1 基于RTS/CTS的Semi-TCP擁塞控制算法

根據船舶自組網的特點,船舶在水面上以一定的速度移動,信道損耗較大,將擁塞控制下放到MAC層是提高網絡性能最簡便且高效的方法。在IEEE802.11無線網絡中,基于DCF接入控制模式下的RTS/CTS有著非常廣泛的運用,下面就詳細介紹基于RTS/CTS的Semi-TCP擁塞控制算法。

RTS/CTS握手協議即請求發送/清除發送協議,是基于競爭的介質訪問控制協議CSMA/CA(Carrier Sense Multiple Access with Collision Avoidance,帶沖突避免的載波偵聽多址接入)的一種媒體接入控制方式[9],其采用4次握手(RTS-CTS-DATA-ACK)的方式[10]。相比于基本的媒體接入控制方式(2次握手DATA-ACK),它的提出是為了解決隱藏終端[11]問題。隱藏終端是指在接收節點的覆蓋范圍內而在發送節點的覆蓋范圍外的節點,如圖1所示。

圖中節點A向B發送數據,節點C也有數據需要發往D,圖中所示情況下的C節點就是一個隱藏終端,若采用的是二次握手的接入控制方式,那么其在監聽到信道空閑后向D發送數據,但是B同時處在A和C的接收范圍內,因此會造成B在接收數據時發生碰撞。采用RTS/CTS之后,即使C收不到A的RTS幀,仍可以收到B的CTS幀然后進行退避,從而解決了這種情況。下面要討論的Semi-TCP算法就是基于該握手協議。

1.2 算法基本思想介紹

基于RTS/CTS的Semi-TCP算法也分為節點內和節點間擁塞控制[12],節點內擁塞控制原理這里不再贅述,下面就節點間的擁塞控制詳細介紹。

根據RTS/CTS協議,假設節點A向節點B發送數據,在爭取到發送機會后發送數據之前需要向節點B發送RTS幀,節點B收到RTS幀后回復CTS幀。基于RTS/CTS的Semi-TCP擁塞控制算法中,利用RTS和CTS幀中的空閑位攜帶擁塞信息,以表明自己是否處于擁塞狀態[13-15]。從而引入了2種控制幀——帶擁塞狀態信息的請求發送幀(Request-To-Send-with-Congestion-status,RTSC)和帶擁塞狀態信息的允許發送幀(Request-To-Send-with-Congestion-status,CTSC),同時增加了一種新的幀——拒絕清除發送幀(negative-Clear-To-Send,nCTS)。下面分別分析3種幀的作用,RTSC:發送節點A向節點B發送數據,若A處于擁塞,則發送RTSC,不擁塞時則發送RTS:

1)nCTS:接收節點B在收到RTS幀之后,判斷自身擁塞狀態,若擁塞則回復nCTS幀,拒絕接收數據,否則回復CTS。若節點A收到nCTS,則不能向B發送數據包。值得注意的是接收節點為目的節點的情況(最后一跳),此時對于擁塞的判斷不再是對于發送緩存進行判斷,而是接收緩存。

2)CTSC:CTSC幀的引入主要是為了解決死鎖的情況,死鎖就是兩擁塞節點A和B需向對方發送數據來解除本身的擁塞,但這2個節點又處于相互拒絕對方的狀態中。

3)若節點A和節點B都處于擁塞狀態,A和B發送緩存中隊首數據都是發送給對方。發送節點A會先發送RTSC幀,節點B會回復nCTS拒絕接收數據。由于節點B的拒絕,節點A和B將處于僵死的狀態,直到超過重傳上限丟掉數據包。因此,當節點B在收到RTSC之后,若判斷出可能出現死鎖,就回復CTSC幀互相幫助解除擁塞。

利用上述3種新的幀,當網絡中某一節點擁塞時,就可以快速的向上游節點傳遞擁塞信息,各上游節點進行逐跳的擁塞控制,最終將擁塞傳到源節點,從源頭減少發往網絡中的數據,以實現更好的網絡通信性能。

2 算法性能改進措施

根據在1.1節中對RTS/CTS握手協議的介紹,RTS、CTS幀會在網絡分配矢量(NAV)域(具體值為控制幀中Duration位)中預約了時隙,以表明收到該幀的節點在多長時間以內需要退避,從而避免發送數據幀時產生碰撞。RTS/CTS協議是為了解決隱藏終端而提出的,但是暴露終端問題也一定程度上影響網絡性能,暴露終端是指在發送節點的覆蓋范圍內而在接收節點的覆蓋范圍外的節點,如圖2所示。

節點C在向節點F發送數據,A也需要向B發送數據,圖示情況中的A節點就是一個暴露終端。A在收到C的RTS后會進行退避,然而實際上各自的接收節點并不在對方的發送節點的接收范圍內,因此,2種數據并不會在接收端發生碰撞,A是可以向B發送數據的。這樣的暴露終端問題就造成了信道的浪費。

不僅暴露終端問題,對于一個數據流較多、負載較重的擁塞網絡而言,自然會有多個nCTS幀的交互,這也會帶來很大的問題,假設有節點A需要發送數據幀給節點B,B回復nCTS,那么節點A在收到之后將不會在原本預約好的時隙中發送數據。如圖3所示,此時周圍的鄰居節點可以分情況考慮。

圖3 nCTS的交互

節點D作為隱藏終端,當收到nCTS之后,根據其Duration會進行相應的退避;節點C作為暴露終端,收到RTS后也會進行退避;節點E能收到2個控制幀,會選擇RTS和nCTS更大的Duration進行退避。至此節點A～節點E都將不能發送數據,從而造成信道的浪費,使得網絡擁塞加劇。

為了解決上述2種問題以優化Semi-TCP的性能,進行如下的算法設計:

1)將nCTS的Duration設為0,解決圖2中隱藏終端的退避問題。

2)節點在收到不是發給自己的RTS幀之后,會記錄下該幀的發送地址,同時開啟一個定時器暴露終端判定定時器(Timer for Exposed Terminal,TET),若在一定時間間隔內沒有收到發往該地址的CTS或者重傳的RTS,則判定自己為暴露終端,可以取消退避。

3)若在TET定時器超時之前收到了nCTS,則取消退避。

4)節點在收到不是發給自己的RTS幀之后,在定時器TET超時前:收到別的節點發來的不是給自己的RTS幀,則記錄下新的地址并且重設定時器;收到不是發給自己的CTS幀無條件按照Duration進行退避。

5)節點在TET定時器開啟的狀態下若收到任何發給自己的控制幀,都按照退避狀態處理。

關于設置的TET定時器的時長,必然需要考慮到重傳RTS的情況,設置滿足要求的最小值。結合RTS/CTS協議進行分析,節點在發送了RTS幀之后,會開啟一個重傳定時器,該重傳定時器的值如式(1)所示,其中,PropDelay為傳播時延,SIFS為短幀間間隔,transmitDelay(CCTS)為CCTS幀的傳輸時延,slotTime為等待的隨機時間。

holdForCts=PropDelay+SIFS+

transmitDelay(CCTS)+

PropDlay+slotTime

(1)

即在這段時間之后,若在該規定時間內沒有收到對方任何回應,則會重傳RTS幀。因此,一個節點在收到不是發給自己的RTS幀之后,如果連重傳的RTS都沒有,那么判定自身為暴露終端。TET定時器時長如式(2),transmitDelay(RRTS)為RTS的傳輸時延。

holdForBackup= (holdForCts-PropDelay)+

transmitDelay(RRTS)+PropDlay

(2)

在TET定時器沒開的狀態下,收到不是發給自己的控制幀的算法流程如圖4所示。

圖4 TET開啟狀態下收到非自己的控制幀處理流程

在TET定時器開啟的狀態下,收到不是發給自己的控制幀的算法流程如圖5所示。

圖5 TET關閉狀態下收到非自己的控制幀處理流程

3 實驗仿真及分析

吞吐量和時延作為網絡性能的重要評判參數,在對Semi-TCP進行的性能測試中,本文中將其作為主要的評判標準。網絡平均吞吐量直觀的表現了網絡的傳輸性能,是考察網絡性能的重要參數,提高吞吐量也是網絡優化協議的最主要的目的。分組時延是指分組從發送節點發出,到目的節點收到分組時的這段時間間隔,它包含了隊列時延、傳輸時延和傳播時延。在采用的Exata仿真軟件的統計中,以上參數都會直接給出方便觀察比較。

3.1 仿真場景及參數設置

本節只針對船舶自組網進行仿真,為了能體現出船舶自組網的特點,有必要建立一個遠距離的動態的仿真場景,海上的部分節點按一定速度運動,并配合適當的信道衰減模型,同時,要對擁塞控制算法進行測試,必然需要建立擁塞的場景,因此,加上了多個應用數據流,從而盡可能體現出網絡吞吐量、丟包率、平均分組時延的差異。仿真場景抽象場景如圖6所示。

圖6 船舶自組網仿真場景

場景中各個節點的發送范圍僅覆蓋與其相鄰的節點,節點A發往節點C和節點F的數據流都需要經過中間節點的轉發。節點J到K的數據流主要是為了驗證A作為暴露終端的情況下的Semi-TCP改進算法的性能,B的2個數據流主要是為了造成網絡的擁塞。場景的基本參數設置如表1所示。

表1 仿真場景主要參數

為了方便敘述,本文將基于RTS/CTS的Semi-TCP擁塞控制算法稱為Semi-TCP-RTS,改進算法稱為Semi-TCP-RTS-V2,2種算法的仿真結果與軟件提供的一個TCP的輕量版本TCP-Lite進行比較。

3.2 仿真結果分析

為了分析門限值對于算法性能的影響,將其作為變量進行多次仿真,同時鑒于有多個數據流,統計了各個數據流平均吞吐量的總和并進行了比較,結果如圖7所示。

圖7 擁塞場景下吞吐量隨門限值的變化

由該結果可以看出,2種Semi-TCP算法相較于TCP-Lite,在網絡總吞吐量上都有大幅的提升,這是因為TCP-Lite將由于信道質量不足造成的丟包錯判為網絡擁塞,錯誤地降低了發送窗口,限制了網絡性能。同時Semi-TCP-RTS-V2相較于Semi-TCP-RTS,總吞吐量上稍有下降,針對該結果結合圖8中對發送節點A的負載的對比做出解釋。

圖8 發送節點A負載隨門限值的變化

結合圖8可以發現,節點A的負載相較于整個網絡的平均吞吐量之和小得多,實際上在Semi-TCP-RTS測試結果中,甚至存在節點A的一個數據流建立失敗的情況。這是因為節點A發送數據會同時受到節點J和節點B的影響,不僅充當了J—>K以及B—>C數據流的暴露終端,同時在B—>D數據流中,由于D在其接收范圍內也會影響其發包。再加上節點B的兩個數據流造成的擁塞,更加限制了A發送數據包。因此也就出現了上述結果。

另外還可以明顯發現,在改進算法中,節點A在整個網絡吞吐量下降的情況下,自身的負載反而上升。這說明節點A與另外2個發送節點之間的差距縮小了,也就是說在數據流的公平性上有所改善。這是因為Semi-TCP-RTS-V2中,暴露終端的問題得到改善,因此負載也有所提升。至于圖7中顯示的總吞吐量相較于Semi-TCP-RTS偏低,是由于改進算法中對于暴露終端的判斷需要耗費一些時間,同時節點A在發包時會使得另外兩個發送節點都進入暴露終端的判斷階段,因此才產生這樣的結果。

繼續觀察圖7,可以發現門限值的變化對于網絡整體的吞吐量并沒有造成很大的影響,但是隨著門限值的增加,隊列的平均長度必然也會增加,則平均隊列時延一定會相應的變長,下面針對J—>K數據流中,節點J的平均隊列時延進行數據統計,結果如圖9所示,由于門限值一致,Semi-TCP-RTS和Semi-TCP-RTS-V2并沒有什么差異,整體上升的趨勢也符合預期。

圖9 節點J的平均隊列時延隨門限值的變化

4 結束語

船舶自組網采用IEEE802.11協議標準,本文介紹現有的Semi-TCP-RTS擁塞控制算法,同時提出針對Semi-TCP-RTS的改進算法Semi-TCP-RTS-2,以解決暴露終端以及由于nCTS的交互帶來的信道資源浪費等問題。在Exata仿真平臺分別實現和測試了3種算法,并進行了對比分析。結果顯示,Semi-TCP-RTS-V2算法優于TCP-Lite和Semi-TCP-RTS,同時在節點發送數據的公平性上有所改善。

[1] AFANASYEV A,TILLEY N,REIHER P,et al.Host-to-host Congestion Control for TCP[J].IEEE Com-munications Surveys & Tutorials,2010,12(3):304-342.

[2] HANBALI A A,ALTMAN E,NAIN P.A Survey of TCP over Ad Hoc Networks[J].IEEE Communications Surveys & Tutorials,2005,7(3):23-36.

[3] SARDAR B,SAHA D.Survey of TCP Enhancements for Last-hop Wireless Networks[J].IEEE Com-munications Surveys and Tutorials,2006,8(3):20-34.

[4] CHRISTIAN L,BJORN S,MARTIN M.A Survey on Congestion Control or Mobile Ad Hoc Networks[J].Wiley Wireless Communications and Mobile Computing,2007,7(5):655-676.

[5] FU Zhenghua,GREENSTEIN B,MENG Xiaoqiao.Design and Implementation of a TCP-friendly Transport Protocol for Ad Hoc Wireless Networks[C]//Pro-ceedings of ICNP’02.Paris,France:[s.n.],2002:216-225.

[6] MONZER H A M,SUHAIDI H.Loss Detection and Recovery Techniques for TCP in Mobile Ad Hoc Network[C]//Proceedings of the 2nd International Conference on Network Applications,Protocols and Services.Washington D.C.,USA:IEEE Press,2010:48-54.

[7] 蔡業桂.多跳無線網絡基于RTS/CTS的Semi-TCP擁塞控制算法研究[D].廣州:華南理工大學,2010.

[8] 劉 梅,姜勝明,陸以勤.無線多跳網絡中Semi-TCP 協議的實現[J].計算機工程,2012,38(9):79-82.

[9] 張 偉.無線移動 Ad Hoc 網絡違規行為分析[J].中國科技縱橫,2012,13:62-64.

[10] 虞萬榮.無線自組網MAC協議關鍵技術研究[D].長沙:國防科學技術大學,2006.

[11] 劉志敏,徐鳳英.移動Ad Hoc網絡隱藏和暴露終端問題的研究[J].計算機與網絡,2010,6(1):30-37.

[12] LIU J,SINGH S.ATCP:TCP for Mobile Ad Hoc Networks[J].IEEE Journals on Selected Areas in Communications 2001,19(7):1300-1315.

[13] SUNDARESAN K,ANANTHARAMAN V,HSIEH H Y,et al.ATP:A Reliable Transport Protocol for Ad Hoc Networks[C]//Proceedings of ACM International Sympo-sium on Mobile Ad Hoc Networking and Computing.New York,USA:ACM Press,2003:64-75.

[14] 毛華超.多跳無線網絡服務質量與擁塞控制的聯合設計[D].廣州:華南理工大學,2013.

[15] TASSIULAS L.Adaptive Back-pressure Congestion Control Based on Local Information[J].IEEE Transactions on Automatic Control,1995,40(2):236-250.