面向船舶自组网的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.