星间网络中对TCP捎带确认模式的验证和改良

2018-12-15韩冰龚文斌

电子设计工程 2018年23期

韩冰，龚文斌

（中科院上海微系统与信息技术研究所上海200050）

星间链路不同于地面链路，具有传输线路长，易受干扰的特点，而北斗的星间链路传输速率一般不超过51.2 kpbs，有明确的限制。加上既有的建链目的节点分布不均，路径规划不合理等问题，使得星间网络极易产生阻塞的状况，延迟特性差，最长时延超标的问题极为突出。这在境内卫星向境外卫星发送数据时尤为明显。如何降低星间网络延迟，提高星间网络传输质量，已成为我国北斗卫星的战略重点[1]。

文献[2-3]通过优化路由算法，通过降低跳数和合理设计传输路径的方式来提高整网的性能，文献[4-5]从链路分配问题上入手，提出了更为合理的分配方式，文献[6-7]则是针对Walker星座作了对应的优化，力图设计更为合理的星座以改善整个整网的传输环境。这些研究大多是从星座结构、路径优化和链路分配着手，来提升整网性能，少有研究针对星间链路信息流本身的传输模式。本文基于对现有星间网络信息流组成结构的研究入手，针对性传统TCP的传输模式有效信息流利用率太差的问题，设计一种适合星间网络传输的TCP捎带确认模式，期望通过精简信息流，提高有效信息流利用率的方式来改善星间网络拥塞的环境，改善时延特性。

1 信息流模型

卫星星间链路[8]主要有3种信息流[9]，遥控、遥测和运控信息，图1为信息流模型。

相关定义如下:S1～S3为3种信息流的总帧数，SE为有效帧数，SA为确认帧数，SR为重传帧数，SAR为重传确认帧数。AS1～AS30为发送 ACK 计数值，AR1～AR30为接收ACK的计数值。

图1 整星对外信息流

遥控信息和运控信息由地面站和运控站向可见卫星发送，遥控信息负责管理卫星的日常运行，运控信息则承载着卫星的具体业务，这两种信息流均很重要，故采用TCP模式进行传输，故遥控和运控的信息流帧数构成为:

遥测信息无论是下发遥测还是星间传输，都具有一定的重复性，足以弥补误码率带来的负面影响，故通常采用UDP模式传输。遥测的信息流构成为:

由此可见，相比遥测，遥控和运控的传输模式其有效信息流利用率不到一半，我们优化的重点在于对传统TCP的传输模式的改良。

2 TCP捎带确认模式设计

从对信息流的分析可知，确认帧和重传确认帧并不承担具体业务，却大大增加了星间网络的负担，是网络更为拥塞，应将确认帧作为首要优化对象，把确认帧所承载的信息放入正好要回传的信息流（改良数据帧的帧头，使其容纳此确认帧信息），该承载的信息流可以是运控转发，遥控转发，遥测信息中的任何一种。

TCP捎带确认方式的传输模式如图2所示。

在这种模式下，星间网络遥控和运控的信息流帧数构成为:

图2 TCP捎带确认模式

通过这种方式，我们可以节省确认帧和重传确认帧的开销。由于每次运控和遥控的信息我们都采用的是确认帧机制，所以理论上我们降低了运控和遥控的一半开销。

地面捎带确认模式和相关研究过于复杂，且没有考虑星间网络根据路由表时隙表传输的特点，并不适合星间网络，我们需要重新实现星间网络的捎带确认模式，以北斗30星为实验背景，星间网络的捎带确认模式，具体实现步骤为：

1）将每个卫星遥控和运控的缓存细分为30个。本星的每个缓存对应一个它星临时存储发送给此卫星的星间数据包，并额外存储对应此卫星的AS和AR两个值。

2）当A星向B星之间发送运控和遥控的信息流时，我们让A星缓存中ASA的值+1。

3）B星收到来自A星的信息后，B星对应A星的缓存中ARB值+1。每次B星向外发送数据，均会征询对应其他29星的运控和遥控缓存。

4）B星再次向A星发送数据时，若查到对应的ARB值不为0，会将此ARB的值放入发送的数据包，记录所需回传的ACK个数。

5）A星接收到B星的数据包以后，拆包查看包头中装有对应ARB的位置，让ASA-ARB，以此确认收到多少个应收的ACK，并丢掉相应的已缓存的数据包。

6）若超过指定时间未收到ACK，则须开启重传机制[10]再次发送缓存的数据包；若再次发送仍未收到ACK，则扔掉缓存的数据包并将ASA值-1。

注:由于星间网络的特殊性，卫星能力有限，通过设置ACK编号的方式来设计捎带确认模式开销过大，并不十分可行，故采用计数方式。

3 仿真结果

本文实验仿真数据是通过联合软仿进行的北斗30星星间链路模拟的一周运转仿真结果，传输速率设置为102.4 kbps。

其时延统计如表1所示，mode1为传统TCP模式，mode2为TCP捎带确认模式。

由于更改传输模式的方法本质是通过精简信息流改善改善网络拥塞状况，以此来优化时延特性，故我们增添传输速率为51.2 kbps时的实验作为比较，使整网环境更为苛刻，网络拥塞状况更为严重，表2为51.2 kbps时的时延统计。

表1 102.4 kbps的传输时延

表2 51.2 kbps的传输时延

如表中所示，无论是境内传输还是境外传输，TCP捎带模式比TCP模式在时延特性上表现更为优越，尤其是最大时延和平均时延特性的提升。而随着整网环境的苛刻化，这种表现更为突出。

为了进一步验证实验结果，本文在51.2 kbps的传输条件下，对上注信息传输的时延分布做了相应的统计，如图3和图4所示。

图3 mode1在51.2 kbps速率下的时延分布

如图所示，如两组时延分布图所示，TCP捎带模式的运控信息和遥控信息的高时延信息分布均有下降，更多的信息被及时传到。

图4 mode2在51.2 kbps速率下的时延分布

4 TCP捎带确认模式的改良

本文针对另一个较为重要的属性，重传率，对两者进行了比较，如表3所示。

表3 两个模式重传率的比较

上表显示TCP捎带模式相对于传统TCP模式，在重传率上不增反降。网络阻塞问题的缓解优化了星间网络环境，提升了时延性能，但是在重传率上并未带来理想的结果。

故有必要进一步跟踪重传包，并分析其原因（见图5）。

图5 重传包传输时延分析

由此可见，由于传统TCP模式接收到信息立刻发送确认帧，而TCP捎带模式接收到信息后，并不是立即发送回传的ACK，而是等待目的卫星回传的信息捎带回传ACK，是一种延时回传机制。由于卫星的规律性并不能保证目的卫星时刻可见，且需要根据时隙表和路由表配合传送数据，故会造成小部分信息等待回传的时间过长，这种情况一方面会导致卫星内部缓存积压，另一方面会导致回传超时，触发重传，变相增加运行于星间网络的信息流总量，从而恶化星间网络。

同时，我们发现，星间网络的重传帧大量集中于传输延时超过15秒的帧，而这些帧本身占比也很少，故仅针对这类数据，设置合适的阈值[11-13]，切换回传统TCP模式，可以缓解重传率的问题。但切换回传统TCP模式后，重传率虽大为改善，这部分切换回去的信息流并未得到精简，因为回传的ACK帧和重传帧一样都增加了信息流总量。

由于本文设计的捎带确认传输已经是一种延时回传的策略，所以与Block-ACK[14-16]延时回传策略有良好的兼容性，即在达到时间阈值之后，将积压的ACK打包成一帧进行发送。鉴于现在使用的是ACK计数的方式，故只需发送并清零ARB即可，可确保这部分的信息帧得到大量的精简，虽然不如捎带确认方式，但相对于传统TCP模式，仍然有效提升了信息流利用率。

具体步骤:

1）A星向B星传送数据数据到达目的卫星B后，卫星B的对应缓存在累计帧计数ARB的同时记录系统时间戳与之绑定，只在ARB从0到非0的时候记录，之后的累加不更新时间戳。

2）当A星对B星可见时，意味着此时可以发送相应的数据，B星扫描自己的缓存，找到ARB对应的时间戳，将此时的系统时间与缓存中的时间戳作比较，若超过阈值，则切换为Block-ACK延时回传策略，单独回传携带ARB的确认帧，仅需发送一帧。

3）本次实验阈值设置为30秒，根据是65秒重传的设置，以及时隙表60秒会重复一次的特点。表4为此次实验针对重传率的结果。表5为实现切换策略之后的试验统计，mode3为切换模式。