杨 森,吴 彦, 战文杰
星座卫星通信是今后卫星通信的主要发展方向之一,能够支持多业务、多速率、多频段、多体制、多轨道类型,能够有效解决目前中国卫星通信空间段资源不足、轨道类型单一、覆盖范围小、体系不完善、建设规模小、抗攻击能力差、无星间链路、网络化水平低、信息综合能力弱等方面的问题[1]。而且因其宽覆盖范围、优良的传播能力和不受各种地域条件限制等优点成为无线因特网接入的重要途径。但是就中国实际国情,目前还难以建成一个能够覆盖全球的星座卫星通信系统,而首先建立一个区域覆盖的星座系统,然后向全球覆盖过渡,不但可行而且需要,这里研究的对象就是能够覆盖中国领土的24/3/1区域覆盖Walker星座。
目前,24星Walker星座还处于理论研究和验证阶段,对于该系统的网络性能,特别是对于TCP协议在该网络中的性能,没有现成的资料和数据可供参考。信道速率、分组长度、发送窗口的大小和误码率等条件的不同组合都会对TCP协议性能产生不同的影响[2],首先在NS2中建立了24星的星座网络模型[3],然后在该模型下通过仿真给出TCP协议在各种情况下性能表现,为下一步的工作提供理论参考。
TCP协议是一种端到端的协议,为了进行流量控制和拥塞控制,该协议采用了慢启动、拥塞避免和滑动窗等机制,在地面网络中运行非常成功。虽然与静止卫星通信相比,低轨星座卫星通信的通信时延小很多,TCP协议中慢启动算法带来的问题并不明显[4]。但是,低轨星座卫星网络具有变化幅度很大的分组往返时延(RTT,Round-Trip Time)、频繁的切换、较高的信道误码率及信号衰落等特点,这些特点使得TCP协议在卫星移动信道中的效率受到较大影响。
①卫星移动引起信道的频繁切换和网络拓扑的不断变化,使得分组的传输时延大幅变化,而且在某些时刻信道的分组丢失率极高;②雨衰、多径衰落、阴影效应和切换等都会造成信道的误码率急剧增加,造成数据分组在卫星信道上的丢失,而TCP协议无法区分由于拥塞和链路恶化造成的分组丢失,却统一认为是由于拥塞而引起的,这就会降低网络的吞吐量,而且当确认符(ACK,ACKnowledge Character)分组丢失时,吞吐量会进一步恶化[5]。
现采用比较流行的网络仿真软件NS2进行建模和仿真[3],在该软件下建立了一个24星的区域覆盖的星座网络模型,基于该模型对星座通信网络的性能进行仿真。
在NS2中建立一种区域覆盖的24/3/1Walker星座网络模型,该星座提供带状覆盖区,可以覆盖中国全部领土。星座中共有3个轨道面,每个轨道面的8颗卫星建有持续的星际链路,轨道面之间依次通过不同的卫星建立“接力型”星际链路,其中异轨卫星间的“建链”情况如表1所示。
在NS2中除了设置星座系统的基本参数外,对星座网络仿真场景的设置如表2所示。
表2 星座网络仿真场景
首先为了给出该网络的传输时延,在位于北京和广州的两个终端之间建立用户数据报协议(UDP,User Datagram Protocol)连接,承载固定码率(CBR,Constants Bit Rate)业务,假设上下行链路带宽均为256 kb/s,分别给出网络在一个回归周期内和一个轨道周期内的时延特性如图1和图2所示。
图1 一个回归周期内的网络延时
图2 一个轨道周期内的网络延时
在星座网络中,随着星际链路的切换,网络传输延时发生巨大变化,但由于星座运行的规律性,网络传输延时也呈现出规律性。图1给出了一个轨道回归周期的时延,也就是说该网络的时延以回归周期为周期重复。为了清楚的看到星座拓扑变化给传输延时带来的影响,图2给出了一个轨道周期内的时延变化情况,可以看到随着经过的卫星跳数变化,时延急剧变化。
同时,TCP协议的性能受到很多因素的影响,比如信道速率、分组长度、窗口大小、时延以及链路丢包率等,下面给出星座网络中各种条件下的TCP性能,主要用平均吞吐量和平均分组传输时延衡量。由于在NS当中窗口大小是以分组数为单位的,因此,窗口大小和分组长度共同构成TCP中窗口,而且NS中的单向TCP协议的接收窗口通过初始设置为固定值。
当接收窗口为40个分组时,在各种信道速率下,吞吐量和分组传输时延与信道速率和分组长度之间的关系如图3和图4所示。
固定NS中的窗口,不断调整分组长度等效于调整窗口的效果,从图3可以看出,不管信道速率大小,增加分组长度对吞吐量的提升并不是很明显,当分组长度从200增加到1 000字节时,吞吐量大约增加20%。但对分组传输时延的影响却较大,当分组长度从200增加到1 000字节时,分组传输时延增加3倍。
图3 吞吐量、信道速率和分组长度的关系
图4 分组传输时延、信道速率和分组长度的关系
目前,针对各种特殊的信道条件已经提出了多种TCP的改进版本。主要有:
①Tahoe:传统的 TCP,基于丢包的拥塞避免和快速重传,慢启动。
②Reno:Tahoe对丢包非常敏感,1%的丢包率会导致吞吐率降低50%~75%。Reno在Tahoe基础上增加了快速恢复,可以一定程度上缓解这一问题。
③Newreno:Reno的快速恢复算法在“快速恢复”了第一个丢失的segment,即收到一个非重复、有效的ACK之后就退出了快速恢复。这样当同一个窗口中有多个segment丢失时,该算法只能对第一个丢失的包进行快速恢复,导致性能降低。Newreno的快速恢复算法做了小小的改进:在收到非重复、有效的ACK之后,只有这个ACK对发生丢包的窗口内的所有数据做了确认,才退出快速恢复算法。
④Vegas对传统TCP做了相当大的改进,具体如下:a. 更快速的重传:为了避免对操作系统粗粒度时钟的依赖,Vegas在每次重复的ACK到来时,都检查对应的segment是否已经可以超时重传,另外,发生重传时,如果重传的segment是在上一个大小的拥塞窗口下发送的,则不对拥塞窗口做减半操作,这么做可以避免拥塞窗口被过分减小导致传输性能下降;b. 拥塞预测:利用吞吐率的变化调整拥塞窗口,而不是利用丢包来检测拥塞。每收到一个有效的ACK,计算如下三个值:Expected=WindowSize/BaseRTT;Actual=SentData-ActualRTT;Diff=ExpectedActual,其中,BaseRTT是该连接上观测到的最小的 RTT值;ActualRTT是被确认segment被发送到收到 ACK的时间间隔;SentData是ActualRTT内发送的数据量。Vegas定义两个常量a,b(a<b),当Diff<a时,则线性增加拥塞窗口;当Diff>b时,线性减少拥塞窗口。这种拥塞控制方式是在拥塞将要发生时控制,而不是在拥塞发生后控制;c. 慢启动的改进:与拥塞预测的改进机制类似,通过监视吞吐率的变化来决定是否离开慢启动模式。TCP Vegas的最大优点在于拥塞机制的触发只与RTT的改变有关,而与包的具体传输时延无关。由于 TCP Vegas不是利用丢包来判断网络可用带宽,而是以RTT的变化来判断,因此能更精确地预测网络的可利用带宽,其公平性、效率都较好。
现在信道速率为256 kb/s、接收窗口为30、分组长度为800 Byte时,对各种版本的TCP协议在不同丢包率的情况下进行了仿真,平均吞吐量和平均时延分别如图5和图6所示。
图5 各种TCP版本的平均吞吐量比较
图6 各种TCP版本的平均延时比较
从图5可以看出,在窄带星座卫星系统中,Fack的吞吐量始终最小,而NewReno的吞吐量最大,其他几个版本的吞吐量都相差不多,而且丢包率不同时,有不同的性能。吞吐量对丢包率敏感,随着丢包率的增加,吞吐量急剧恶化。在图6中,当丢包率小于0.05时Vegas的时延明显小于其他各个版本的,而且几乎不受丢包率的影响,表现出良好的性能,而其他版本的则相差不多。由于取的是时延的平均值,因此当丢包率稍微增加时,时延反而会变小,但当丢包率进一步增大时,时延则会迅速恶化。
低轨星座系统由于具有良好的覆盖性能和较小的分组传输时延,具有很好的应用前景,但高的误码率和变化的分组时延给网络性能带来较大影响,因此,如何利用该系统作为地面网络的补充进行因特网接入是一个值得探讨的问题。这里对平均吞吐量、平均传输时延与信道速率、窗口大小以及丢包率的关系进行了研究,并在不同丢包率的情况下,比较了TCP各个该进版本的性能,得到了一些有益的结论,为进一步的工作提供参考。
[1]张更新,张杭.卫星移动通信系统[M].北京:人民邮电出版社,2001:700-734.
[2]PARTRIDGE C, SHEPARD T. TCP-IP Performance over Satellite Links[J]. IEEE Transactions on Networking, 1997,11(05):44-49.
[3]徐雷鸣,庞博,赵耀.NS与网络模拟[M]. 北京:人民邮电出版社,2003.
[4]BRAKMO L, MALLEY S, PETERSON L. TCP Vegas: New Techniques for Congestion Detection and Avoidance[C].USA:ACM, 1994:24-35.
[5]叶斌,胡谷雨,倪桂强. DSR路由信息存储的无线 TCP性能改进方法[J].应用科学学报,2007, 25(03):34-38.