基于处理时延的卫星网络TCP拥塞控制算法*

戴帅，肖楠，梁俊，袁天

(空军工程大学 信息与导航学院，陕西 西安 710077)

0 引言

下一代卫星网络是基于IP(internet protocol)的宽带通信网络。低轨(low earth orbit,LEO)卫星由于轨道高度低，具有传输时延和空间损耗小、通信距离远、组网方式灵活、抗毁和抗干扰能力强以及能够实现全球覆盖等一系列优点。TCP(transmission control protocol)协议作为当前IP网络主要使用的传输控制协议，其在LEO卫星网络中的应用得到了广泛的关注和研究。

目前，国内外有关卫星网络TCP拥塞控制算法的研究成果大量涌现，如TCP Reno，TCP New Reno，TCP SACK，TCP Hybla以及TCP Vegas等[1]。其中，TCP Vegas算法能较好地预测网络带宽使用情况，有效应对卫星网络的长时延、高带宽等特点，在卫星网络中有广泛的应用前景。因此，如何在卫星网络中更有效地使用TCP Vegas算法也是近年来研究的热点。文献[2]通过降低拥塞窗口增长速率提出了一种改进型的TCP Vegas 1算法，该算法通过牺牲系统吞吐量有效降低了网络的拥塞概率；文献[3]提出了一种Vegas-b算法，该算法通过加大拥塞窗口的增长速度克服了与TCP New Reno共存时的缺陷，并且能获得比TCP New Reno更大的带宽，提高了协议的公平性。文献[4]中提出了一种改进的Vegas A算法，通过动态调整α和β值，改善拥塞控制机制，从而自动适应网络状况的变化，算法的改进主要表现于拥塞避免阶段。

上述改进算法都是基于卫星链路的往返时延(round trip time，RTT)测量进行设计的，且大都是基于静止轨道卫星网络环境进行实验仿真，并没有考虑卫星节点间距离快速变化和高速移动的问题。在LEO卫星网络中，由于卫星之间快速的相对移动、卫星网络拓扑结构动态变化，使得卫星链路的往返时延不断变化，导致TCP Vegas算法不能准确地计算网络的期望吞吐量，从而造成网络资源的浪费。同时，由于卫星间距离变化范围的不同，传统TCP Vegas算法存在带宽分配的不公平性问题。

本文在分析LEO卫星网络特性的基础上，深入研究了卫星网络TCP Vegas拥塞控制算法，针对Vegas算法在LEO卫星网络环境中存在的问题，提出了一种基于处理时延的改进型拥塞控制算法——TCP Vegas_PD(TCP Vegas based on processing delay)。该算法针对网络中卫星节点高速运动的特点，充分考虑LEO卫星网络拓扑动态变化对RTT的影响以及带宽分配的公平性，通过测量一次通信过程中各卫星节点的最大处理时延，屏蔽网络拓扑结构变化对TCP Vegas算法性能的影响，从而更加精准地测量网络状态，提高了网络吞吐效率，增加了网络性能的稳定性，为卫星网络TCP拥塞控制算法的改进提供了一个新思路。

1 卫星网络特性对TCP协议性能的影响

TCP机制的有效运行依赖于下面3个假设[5]：①数据包的丢失一定是由网络拥塞所引起的；②网络的拓扑结构是稳定的；③通信路径上的传播时延也相对稳定，这些在LEO卫星网络中并不适用。与地面有线网络相比，LEO卫星网络环境要复杂得多，存在许多影响TCP协议性能的因素，主要可以归纳为以下几点：

(1) 往返时延动态变化

LEO卫星网络具有高动态的连接特性，网络拓扑结构频繁变化会改变数据包传输时经历的跳数和传播距离，使RTT的测量值发生很大波动。由于TCP的超时重传时间是基于RTT设置的，不准确的RTT测量值会导致TCP过早或过晚地重传报文段，并缩小拥塞窗口，降低了吞吐量，同时造成网络性能的不稳定。

(2) 传播延迟长

在大多数LEO卫星通信系统中，单跳传输时延大约为20至25 ms。过长的RTT使得慢启动(slow start)阶段的TCP拥塞窗口增长速度变得十分缓慢。同时，长传播延时在TCP检测和恢复丢失数据操作上影响很大，降低了卫星网络的吞吐效率。

(3) 信道误码率高[6]

通常在空间卫星通信环境下信道随机误码率在10-4～10-7左右，同时卫星信道还受天气影响。由于TCP协议默认信道出现丢包是网络拥塞造成，因此当信道传输条件恶化，由链路误码造成数据丢失时，TCP协议会减少数据发送窗口值，错误地启动拥塞控制策略，导致发送速率和吞吐量降低，不仅影响了TCP协议的传输效率，还浪费了卫星信道带宽。

(4) 信道带宽不对称[7]

由于卫星通信系统地面发射设备昂贵、卫星转发器资源有限、收发送功率和天线尺寸等条件的限制，卫星前向链路带宽大于反向链路。带宽不对称性会造成确认速度慢、不必要的超时重传和数据突发等问题，从而降低网络的吞吐量。

(5) 通信链路易中断

卫星通信具有高动态的连接特性，对于非静止轨道卫星，连接可能会因为地面站切换、网络拓扑结构改变、天气情况以及轨道变化等多种原因而被周期性地中断，这与TCP有效运行的稳定的有线链路环境有较大差异，阻碍了TCP协议在卫星网络中性能的发挥。

综上所述，LEO卫星通信环境与地面通信环境存在诸多差异，导致了传统的TCP协议直接应用于在卫星环境中时传输效率低下，需要针对LEO卫星通信环境的特点对TCP协议作出适当的改进。

2 TCP Vegas算法简介

TCP Vegas算法[8-9](以下简称Vegas算法)的基本原理是通过观测RTT的变化来判断网络的拥塞状况，并作出相应的调整。Vegas算法根据Expected_Rate(期望吞吐量)和Actual_Rate(实际吞吐量)的差值Δ来估计网络中可用的带宽。其核心算法如下：

Expected_Rate=cwnd(t)/Base_RTT，

(1)

Actual_Rate=cwnd(t)/RTT，

(2)

Δ=Expected_Rate-Actual_Rate，

(3)

式中：Base_RTT为所有观察链路往返时延的最小值，一般为连接建立后的所发送第1个数据包的RTT，此后可随每次测得的RTT值的情况进行不断更新；cwnd(t)为当前拥塞窗口的大小，即可发送的数据包数；RTT为当前测得的链路往返时延。

若实际吞吐量和期望吞吐量数值很接近，Δ的值较小，可以认为网络没有发生拥塞；若实际吞吐量远小于期望吞吐量，Δ的值较大，则网络很有可能出现拥塞状况。据此，Vegas算法可以更新拥塞窗口，以保证网络传输的正常运行。调整拥塞窗口的算法可描述如下：

(4)

式中：δ=Δ·RTT；α和β为定义的2个门限值，且0<α<β，α触发发送速率的提升，β触发发送速率的降低，其经验值分别为1和3[10]。

由于Vegas算法是根据实际网络状况来决定何时结束拥塞控制窗口的指数增长，而不是像TCP Reno等算法那样根据丢包或预设的窗口上限来结束慢启动，因此可以在避免发生拥塞的前提下，尽可能在慢启动状态使发送速率接近网络可用带宽，使TCP连接很快达到高吞吐量。在拥塞避免状态，Vegas算法对拥塞控制窗口调节及时而平缓，能避免剧烈振荡而稳定在最佳值附近。

3 LEO卫星网络中TCP Vegas算法的改进

虽然现有地面网络拥塞控制主要采用的是TCP Reno算法，但是卫星网络的长时延使得Reno算法拥塞窗口增加缓慢且变化剧烈，导致网络吞吐效率低下。Vegas算法由于采用了新的拥塞避免机制，能比较准确地测量网络的拥塞状况，所以Vegas算法比Reno算法更加适用于卫星网络。但Vegas算法以RTT为主要参数来控制发送窗口的变化，而LEO卫星通信网的拓扑结构是实时高动态变化的，这会造成RTT的非拥塞原因增大。Vegas算法本身并没有能力识别RTT的增大是由网络拥塞造成的还是由路径变化造成的。如果是路径的改变导致RTT的增加Vegas算法也会减小发送窗口，浪费了网络资源，降低了TCP协议的性能。

3.1 TCP Vegas在LEO卫星网络中存在的问题

在LEO卫星网络中，传播时延随着卫星之间距离以及传输路径的变化而变化，通信距离每增加1 000 km，会带来额外的13.3 ms的往返时延。以具有全球覆盖能力的极轨道星座为例[11]，星座参数设置如表1所示。由于卫星之间高速的相对运动以及两极地区星间链路的断开与重建，其网络拓扑结构变化频率达平均3～4 min/次。此外，由于卫星星座覆盖缝隙的存在(即反向运动卫星之间不建立星间链路)，使得网络通信时延存在较大突变。

表1 LEO卫星网络参数设置Table 1 LEO satellite network parameters configuration

通过STK场景仿真可知，该LEO卫星通信系统的空间拓扑结构如图所1示。

图1 LEO卫星系统空间分布示意图Fig.1 LEO satellite system spatial distribution diagram

选取A地(34°N，109°S)与B地(47°N，88°S)为地面通信终端，对两地之间通信往返时延RTT(未考虑卫星处理时延)进行仿真(仿真时间86 400 s)，结果如图2所示。

由图2可知，在不考虑卫星星上处理时延的情况下，A地至B地之间通信的RTT是实时变化的，其中最大RTT为328.6 ms(通信终端位于覆盖缝隙两侧时)，最小RTT为33.6 ms，即由于通信路径距离变化引起的往返时延差值高达295 ms。

一般情况下，Vegas算法认为当前测得的往返时延与最小往返时延的差值是排队时延[12]。在LEO卫星网络中，往返时延与最小往返时延的差值中， 很大一部分是由于传播时延的变化引起的。巨大的传播时延差值可能会隐藏掉排队时延对往返时延的影响，成为决定往返时延的主要因素，致使Vegas算法不能准确预测网络的拥塞状况[13]。

此外，卫星间距离变化范围的不同导致Vegas算法的性能也不同。卫星轨道高度越高，往返时延RTT的变化范围越大，Vegas算法的性能也就越差。当卫星网络拓扑结构改变使得端到端通信路径长度变化范围增大时，当前往返时延与最小往返时延的传播时延差值增加，而这种增加与网络的拥塞状况无关，相反地，发送终端应该根据带宽时延积的增大，相应地增大拥塞窗口。但是，在Vegas算法中，发送终端会误认为往返时延增大是由于网络状况恶化引起的，进而减小拥塞窗口。可见，在LEO卫星网络中，由于网络拓扑结构动态变化使得往返时延变化较大，导致Vegas算法存在带宽分配的不公平性。

3.2 Vegas_PD算法

针对以上问题，本文提出一种新的拥塞控制算法——Vegas_PD算法。该算法在保留原Vegas算法拥塞控制机制的基础上修改了最小往返时延的计算方法，即将空间传播时延与卫星星上处理时延分离开来。由于卫星空间传播时延不能反映网络的拥塞状况，因此Vegas_PD算法只利用星上处理时延作为拥塞窗口调整的依据，从而更加精准地反映网络状态的变化情况。

图2 A地-B地往返时延变化情况Fig.2 Position A-B round-trip delay changes

另一方面，考虑到一次通信过程中所历经卫星的最大星上处理时延完全可以反映整个网络的拥塞情况，Vegas_PD算法只需测量一次通信过程中的最大星上处理时延，然后根据每次测得的最大处理时延与基准处理时延的差值动态调整拥塞窗口的大小，从而有效屏蔽了由于卫星网络拓扑结构改变带来的时延变化的影响，提高网络的吞吐效率。

TCP协议报文格式选项部分(长度可变)的时间戳选项(10字节)主要用来计算往返时延RTT和防止序号绕回。在传统TCP协议中，时间戳选项主要包括时间戳字段(4字节)和时间戳回送回答字段(4字节)，发送终端在发送报文段时把当前时钟的时间值放入时间戳字段，接收方在确认该报文段时把时间戳字段复制到时间戳回送回答字段，因此发送方在收到确认报文后可以精确地计算出RTT。

在Vegas_PD算法中，为了精确获得每颗卫星的星上处理时间，需要对时间戳选项的功能做适当的修改，即时间戳不仅记录报文段的发送和接收时间，还需记录该报文段每一次经卫星转发时入队列时间(in_queue_time)和出队列时间(out_queue_time)。同时，在选项部分增加4字节的处理时间记录字段node_processing_time，记录最大处理时间max_node_processing_time。当该报文段被转发至另一颗卫星时，由当前卫星计算出上一颗卫星的星上处理时间并由处理时间记录字段进行记录。

node_processing_time=out_queue_time-in_queue_time.

(5)

与此同时，时间戳选项记录下该卫星的入/出队列时间，在报文段下一次转发时再次计算星上处理时间，若该处理时间大于上一颗卫星的处理时间，则处理时间记录字段更新为当前处理时间，否则保持不变。当报文段最终被转发至目的终端时，由接收端计算出最后一颗卫星的处理时间并与处理时间记录字段的记录值进行比较。这样就可以保证当数据报文段从发送端成功发送至接收段整个过程中处理时间记录字段始终记录的是最大星上处理时间，该处理时间随接收端的返回ACK(acknoweldgement)发送至发送端，发送端依据网络中卫星的max_node_processing_time判断网络当前拥塞状况。

需要说明的是，在Vegas_PD算法中，由于cwnd(t)大小的调整不再依据往返时延RTT，原Vegas算法中利用期望吞吐量与实际吞吐量差值来计算Δ值的算法已不再成立。考虑卫星的星上处理时间主要是报文段的排队时间，可以利用当前报文段当前测得的排队时间与卫星最大排队时间的比值作为Δ值。假设星上缓存大小为sat_buffer，卫星转发速率为v_sat，则星上的最大排队时延为

(6)

一个报文段从发送端传输至接收端的最大排队时延为max_node_processing_time，则Δ为

(7)

一般认为，若当前队列长度超过最大队列长度的2/3时，认为网络负载较重，发生拥塞概率较大；若当前队列长度小于最大队列长度的1/3时，则认为网络负载较轻，发生拥塞概率较小；否则网络处于正常工作状态。因此，取门限值α=1/3，β=2/3，结合式(4)，Vegas_PD算法中拥塞窗口调整的核心算法如下：

(8)

式中：δ=Δ。

此外，由于卫星网络拓扑结构改变造成的时延增大有可能超过发送端的超时重传时间RTO(retransmission time-out)，从而引发发送端拥塞窗口减半重新进入拥塞避免阶段，因此需要考虑每一次时延变化对RTO的影响。RFC 2988建议使用下式计算RTO：

RTO=RTTs+4RTTD,

(9)

式中：RTTs为加权平均往返时延；RTTD为RTT偏差的加权平均值。

每当第1次测量得到RTT样本时，就取所测量得到的RTT样本值，以后每次测量得到一个新的RTT样本，RTTs按照下式进行更新：

RTTs(i+1)=(1-θ)RTTs(i)+θ·RTT(i+1)，

(10)

式中：0≤θ≤1，θ值越大表示新的RTTs值受新的RTT样本的影响越大，RFC 2988推荐的θ值为0.125。

RTTD是与RTTs和RTT样本之差有关。RFC 2988建议，当第1次测量时，RTTD值取为测量到的RTT样本值的一半，在以后测量中，则使用下式更新：

RTTD(i+1)=(1-λ)RTTD(i)+λ|RTTs(i+1)-

RTT(i+1)|，

(11)

式中：0≤λ≤1，其推荐值是0.25。

Vegas_PD算法的具体实现流程如图3所示。

图3 Vegas_PD算法的基本流程Fig.3 Vegas_PD algorithm of the basic flow chart

4 算法性能仿真

为了验证TCP Vegas_PD算法的性能，本文采用了以下2种仿真软件：①卫星仿真软件STK，主要用来仿真卫星网络拓扑结构，版本为8.1.1；②网络仿真软件NS2，主要用来仿真算法性能，版本为2.28。仿真运行环境为Windows XP。

本文仿真实验采用的网络拓扑结构如图4所示。

其中LEO卫星通信网采用3.1中的卫星网络模型，具体参数设置如表1所示；选取A地作为地面固定发送端，B地作为固定地面接收端，对2个终端之间采用Vegas_PD算法和传统Vegas算法通过LEO卫星网进行通信时的算法性能进行仿真分析，主要网络仿真参数设置如表2所示。

图4 实验仿真拓扑结构图Fig.4 Experimental simulation topological structure

表2 主要网络仿真参数设置Table 2 Main network simulation parameters Settings

仿真参数卫星缓存/packets星上转发速率/(Mbit·s-1)星间链路带宽/MHz星地链路带宽/MHz报文长度/bit初始窗口/packets取值5010251520030

使用上述LEO卫星网络拓扑结构和仿真参数配置，分别对Vegas算法和Vegas_PD算法进行了仿真，仿真时间为0～36 000 s，得仿真结果如图5，6所示。图6给出了网络吞吐率的比较(仿真时间3 600 s)，本文吞吐率定义单位时间内为卫星实际转发的数据量与所能转发的最大数据量的比值。

图5 Vegas_PD算法与Vegas算法拥塞窗口变化比较Fig.5 Vegas_PD algorithm compared with Vegas algorithm congestion window changes

图6 Vegas_PD算法与Vegas算法吞吐率变化比较Fig.6 Vegas_PD algorithm compared with Vegas algorithm throughput rate changes

通过仿真可知，由于Vegas_PD算法屏蔽了卫星网络拓扑结构改变带来的影响，仅仅利用星上排队时延作为拥塞窗口调整的依据，使得拥塞窗口的变化更能精确反映出当前网络态。传统Vegas算法利用RTT作为窗口调整依据，卫星网络拓扑结构的改变对算法性能造成了较大影响。图5中，随着RTT的不断增大拥塞窗口持续减小，特别是当通信终端处于覆盖缝隙两侧时，cwnd的值随着RTT的急剧增大减小至0，但实际上此时RTT的变化只是由于网络拓扑结构的变化造成的，网络并未处于拥塞状态。由于Vegas算法未能正确区分RTT增大的原因，导致cwnd错误地减小，浪费了大量卫星资源，同时由于后续通信过程中没有足够且持续减小的RTT，使得cwnd无法增至初始窗口(最大为17)。从图中观察还可发现，Vegas_PD算法拥塞窗口的变化范围为27～45(Vegas算法拥塞窗口变化范围为0～32)，提高了网络的稳定性。

由图6可知，Vegas_PD算法的平均吞吐率在0.587 8，而Vegas算法的平均吞吐率只有0.341 5，相比之下提高了61.15%，且Vegas_PD算法的吞吐量上下波动较小，而Vegas算法由于受拥塞窗口减半的影响上下波动较大，体现了Vegas_PD算法在系统稳定性上的优越性。

为了验证Vegas_PD算法的公平性，在上述LEO卫星网络拓扑结构中，使用轨道高度分别为780，1 000，1 450，2 000与2 500 km的卫星网络对Vegas_PD算法及Vegas算法的吞吐率进行仿真，结果如表3所示。

表3 平均吞吐率比较 Table 3 Average throughput rate comparison

从表2中可以看出，随着卫星间距离变化范围的增大，Vegas算法在卫星网络中的性能不断下降，而在Vegas_PD算法中，卫星之间的距离变化对吞吐率影响很小，几种情况下的吞吐率几乎相同。由此可知，Vegas_PD算法可以改善Vegas算法中网络资源分配的不公平性，使时延变化较长业务的吞吐率可以和其他业务的吞吐率达到同一水平。在Vegas算法下，当卫星轨道高度为2 000 km时，吞吐率比轨道高度为780 km时低67.14%，而在Vegas_PD算法下，吞吐率仅相差7.2%。

5 结束语

与传统TCP Vegas算法相比，TCP Vegas_PD算法有效屏蔽了LEO网络高动态变化的拓扑结构带来的RTT的剧烈变化对Vegas算法性能的影响，利用星上处理时延作为拥塞窗口调整的依据更加精准地反映了当前网络状态变化情况，提高了卫星网络资源的利用率。通过STK场景仿真与NS2网络仿真，验证了Vegas_PD算法的有效性，结果表明Vegas_PD算法在系统吞吐量上较传统Vegas算法有较大提高，且表现出了较好的公平性。

参考文献：

[1] 刘光华,王辉.LEO卫星网络中TCP协议性能研究[J].计算机工程,2010,36(14): 96-98.

LIU Guang-hua, WANG Hui. Research of TCP Protocol Performance in LEO Satellite Network[J]. Computer Engineering, 2010,36(14): 96-98.

[2] 拱长青,赵志刚,王光兴. LEO卫星网络中TCP Vegas拥塞控制算法研究[J].小型微型计算机系统,2006,27(1): 54-57.

GONG Chang-qing, ZHAO Zhi-gang, WANG Guang-xing. Research of TCP Vegas Congestion Control Algorithm over LEO Satellite Networks[J]. Journal of Chinese Computer Systems，2006,27(1): 54-57.

[3] 王斌,陈元琰,冯伟,等.TCP Vegas-b：TCP Vegas改进算法[J].计算机工程与设计,2011,32(2): 438-441.

WANG Bin, CHEN Yuan-yan,FENG Wei,et al. TCP Vegas-b: Enhanced TCP Vegas Congestion Control Algorithm[J]. Computer Engineering and Design, 2011,32(2): 438-441.

[4] 王斌，陈元琰，胡愚. TCP Vegas拥塞避免机制的改进算法[J].计算机应用，2010，30(9)：2486-2500.

WANG Bin, CHEN Yuan-yan, HU Yu. TCP Vegas-W：Enhanced TCP Vegas Congestion Avoidance Mechanism[J]. Journal of Computer Applications，2010，30(9)：2486-2500.

[5] SRIJITH K N, Lillykutty Jacob, ANANDA A L. TCP Vegas-A: Improving the Performance of TCP Vegas [J]. Computer Communications, 2005, 28(4): 429-440.

[6] 王平,顾学迈.LEO卫星网络中TCP协议性能及路由策略研究[J].南京理工大学学报,2007,31(1): 87-91.

WANG Ping, GU Xue-mai. Routing Strategy to Avoid Blind Retransmission of TCP in LEO Satellite Network. Journal of Nanjing University of Science and Technology, 2007,31(1): 87-91.

[7] XIAO Xing-quan，FU Zhong,LIU Ge. A Backup Data Network for Power System Automations Based on Satellite Communication[C]∥IEEE/International Conference on Power System Technology，Washington DC:AIA,2010:158-164.

[8] Lawrence S Brakmo, Sean W O’Malley, Larry L Peterson. TCP Vegas: New Techniques for Congestion Detection and Avoidance[C]∥Proceedings of ACM SIGCOMM’94，USA: ACM, 1994:24-35.

[9] Andrea De Vendictis,Andrea Baiocchi,Michela Bonacci. Analysis and Enhancement of TCP Vegas Congestion Control in a Mixed TCP Vegas and TCP Reno Network Scenario [J].Performance Evaluation (S0166-5316), 2003, 53(3): 225-253.

[10] BRAKMO L S, PETERSON L. TCP Vegas: End to End Congestion Avoidance on a Global Internet [J]. IEEE Journal of Selected Areas in Communication (S0733-8716), 13(8): 1465-1480, 1995.

[11] 万鹏，王瑞军，黄薇. 空间信息传输TCP扩展协议研究与性能分析[J].飞行器测控学报，2010，18(6)：11-16.

WAN Peng，WANG Rui-jun，HUANG Wei. Analysis of the Performance of TCP and Its Extension Protocol for Space Communication[J]. Journal of Spacecraft TT&C Technology，2010，18(6)：11-16.

[12] 顾明，张军，苏东林. 大带宽时延积网络TCP Vegas自适应慢启动算法[J]. 电讯技术，2007，15(4)：27-30.

GU Ming, ZHANG Jun, SU Dong-lin. An Adaptive Slow Start Algorithm of TCP for Large BDP Networks Vegas[J]. Telecommunication Engineering，2007，15(4)：27-30.

[13] 官骏鸣,孙恩昌,方济平,等.卫星链路上TCP协议问题透析[J].无线通信技术,2004，13(2): 47-50.

GUAN Jun-ming, SUN En-chang, FANG Ji-Ping，et al. Performance Analysis of TCP over Satellite Link[J].Wireless Communication Technology, 2004，13(2):47-50.