宽带卫星网络多媒体大容量数据短时延传输方法

刘尚昆

（中央广播电视总台，北京 100859）

0 引 言

随着社会的发展，人们对于网络和通信的要求已经不局限于有线和基于通信基站的无线通信。目前在光纤覆盖区域，高速、低延时的无线、有线通信网络已经能够充分满足各行各业对于数据传输的需求，特别针对媒体行业，大容量多媒体数据的传输在上述环境下已经得以满足。然而对于一些特殊行业而言，其工作场景往往较为复杂，在有线网络尚未覆盖或通信光缆暂未覆盖的区域，如高山、沙漠、草原、海洋等环境下，网络基础设施不可能完全覆盖。要想获得高质量的网络通信服务，只能借助卫星实现地空网络的交互。传统的卫星通信环境较复杂，卫星资源较紧张，因此，传输速率、传输时延都无法与有线网络相比拟。随着空间技术的发展，高速、低时延的宽带卫星网络成为可能。随着全球空间竞赛的展开，各国开始利用低轨、中轨、高轨卫星搭建覆盖全球的通信网络。对于很多场景而言，传统的光纤通信网络无法覆盖到，只有借助卫星网络完成通信。

对于传媒行业而言，利用网络进行大容量的多媒体数据传输是重要环节之一。高实时性的数据传输能够有效确保信息的及时传达，保障新闻资讯的时效性。因此，传媒行业是最先利用卫星通信方式进行多媒体数据传输的行业之一。以卫星电视和直播为例，利用卫星进行全球实时转播，已经成为很多重要赛事和活动的首选传播途径。然而，当前面对多媒体大容量数据，宽带卫星网络还有诸多限制，比如时延较高、带宽不足等问题。针对带宽不足问题，实质上只要部署足够的卫星资源即可应对。然而，对于时延问题，则需要从多方面予以解决[1]。目前主流的思想是面向通信协议进行时延优化。本文将围绕宽带卫星网络多媒体大容量数据短时延传输进行研究，对相应的技术和方法进行设计验证，进而获得更高的实时性。

1 卫星网络及其通信流程

卫星网络实质上是以卫星作为通信链路的中转和路由设备，使得地面设备之间、空间设备与地面设备、空间设备之间能够相互通信。图1展示了一套完整的LEO宽带卫星网络系统。

图1 卫星网络通信示意图

如图1所示，空中多个卫星共同构建了类似地面蜂窝网络的星间链路，确保地面相应区域始终有卫星信号覆盖。当地面或空间需要进行网络通信时，用户侧终端设备利用手持终端将数据发送至卫星，由卫星对数据包进行接收、调解、交换、变频，并进一步选择适当的路由进行传递，进而将数据传递到目标地址。该过程可表述为图2。由此可看到，当终端与用户端建立连接后，卫星网络用户之间的交互就可以单纯通过卫星网络进行，摆脱了对地面基础设施的依赖。当然，与传统网络进行交互，还是要通过信关站进行中转[2]。

图2 卫星网络通信关键流程

2 IP网络时延及其构成

网络时延是指在通信网络中一个报文从发出方到达目的地所需要的时间。网络时延是任何类型网络都不可避免的一个现象，通常被用来评估网络质量。图3对网络传输的过程以及时延的分布进行了列举[3]。从网络时延的构成来看，网络时延可分为节点时延以及传输时延。

图3 网络传输过程示意图

节点时延是指在各个传输节点上所消耗的时间，可进一步分为处理时延、排队时延以及发送时延。当数据包流向某个节点后，该节点首先对数据包头部进行解析，并进一步校验数据包完整性、分配传输路径，这些处理过程的耗时统一被称为处理时延。当数据包在节点上处理完成后，将进入链路传输队列，此时等待前序链路数据包传输完成的时间即为排队时延。而发送时延则是路由节点将数据包完整发出到链路上所消耗的时间，该时间可通过链路传输速率和数据包大小来计算[4]。

传输时延是指数据包从一端路由设备到另一端路由设备的总耗时。该时延可通过两路由间的距离、介质传输速率来计算。

由上述两类时延可看到，对于数据包较小的报文，其网络时延中处理时延占比较高；而对于数据包较大的报文，传输时延占比较高。在网络的传输距离和传输介质（传输方式）既定的情况下，传输时延只能靠路由算法分配更短的传输距离来缩减，而处理时延则需要对现有的节点处理逻辑进行优化。

3 宽带卫星网络对TCP性能的影响分析

TCP协议是一种典型的互联网协议。在TCP连接建立过程中，发送与接收端将进行三次握手，并通过握手数据包判断是否完成了建立，以及通道是否需要维持。这一过程中，TCP设置了一系列的指标作为判断和逻辑依据。在常规的地面网络环境下，TCP协议能够很好地支撑各类应用。

与传统网络环境相比，卫星网络环境下的信道、传输模式往往更复杂，典型的影响如下。

3.1 传输时延显著增加

首先，拥塞窗口会表现出增长缓慢的问题。TCP协议通常根据传输数据的大小对窗口容量进行动态调整。然而卫星通信环境下，数据往返存在较大延迟，这就使得窗口的调整更加缓慢。这一现象使得TCP连接过程始终处于慢启动状态，网络带宽无法高效利用。在多媒体大容量数据传输时，TCP整体的传输效率显著降低[5]。

其次，丢失数据包检测的时间会显著拉长。TCP协议会根据数据包的超时情况判断数据包是否丢失，并判断是否进行补发，以保证数据完整性。然而在地空通信中，往返时延（Round-Trip Time，RTT）值可能因卫星网络的高动态性表现出跳动较大的特性，这就使得TCP协议在测量RTT的时候无法获得客观精准的数值，进而做出不正确的重发，降低总体传输效率，提升总体时延。

最后，存在接收窗口受阻情况。前文提到，卫星通信下，TCP协议可能长时间处于慢启动状态，这就使得接收窗口大部分处于受阻状态。式1表述了往返时延与窗口大小的关系。

式中：Tmax为传输速率，RTT为往返延时，Wmax为窗口大小。由式（1）可以看到，最大传输速率与RTT成反比，与Wmax成正比。对于TCP协议，单窗口传输上限为64k，在RTT无法显著降低且窗口受阻的情况下，数据传输同样存在限制。

3.2 数据存在更高的误码率

任何网络通信都有一定的误码率。误码出现后，将会触发重发机制，进而增加时延。对于卫星通信而言，可能存在两种情形。

其一是数据包损坏引发的误码。在传统地面传输过程中，通常较难出现因传输导致的数据包损坏，而地空通信中，这一问题出现的概率更高。当出现数据包损坏，TCP协议无法分辨，会认为是拥塞导致的问题，因此会自动降低传输速率。这就显著提高了传输时延。

其二，在确实由于拥塞导致的数据包丢失情形下，TCP协议本身并无较好的处理方式，只能通过逐个确认并恢复的机制对数据包进行重发和补全，这会显著增加处理时延。

3.3 收发速率不对称

卫星链路的不对称是其天然特性之一。这是由于卫星设备转发资源昂贵且受限。这一现状会使得发送端往往不能及时获得反馈信息，数据包确认慢。同时，由于双向通信不对称，可能触发重发机制，降低通信效率。此外，数据突发也是其典型的现象之一。上述问题同样会显著拉长传输和处理时延。

4 基于TCP优化的宽带卫星网络多媒体大容量数据短时延传输方法

从上述论述可以看出，传统TCP协议在卫星宽带通信中存在适应性问题，特别是在卫星通信环境下，传统TCP协议会增加传输时延和处理时延。因此，针对多媒体大容量数据传输，要获得更低的卫星通信时延，就需要对TCP协议进行适当优化。

4.1 TCP参数优化

在时延优化方面，首先可从降低节点处理时延的角度入手。对TCP协议而言，节点转发中处理的内容主要是TCP的头。从前文的分析中可看到，在TCP协议中，窗口增加会显著增加传输效率。目前较为常见的TCP协议有RFC1323协议和RFC2414协议。在进行TCP协议优化时，通过对RFC1323模块进行修改，增加窗口数，进而扩大吞吐量，是显著提升传输效率的方法之一[6]。式（2）表示了窗口大小与拥塞之间的关系。

式中：MSS表示最大分段大小，W表示窗口大小。以式（2）为例，若在扩大窗口时产生了拥塞，则自动将窗口设置为1。利用这一规则，也可考虑通过修改TCP的RFC2414协议中的窗口初始参数，缩短设备启动时长，进而提高TCP传输效率。

这一优化思路不通过延迟对窗口进行缩减，能够显著缩短启动时间。此时的启动时间可表达为式（3）。

式中：Tss表示慢启动时间，WA表示最大允许接收窗口，W1表示初始窗口。

这一机制能够对窗口进行动态调整，以适应特殊情形，缩短慢启动周期，提升处理和传输效率，降低时延。然而，这一修改可能导致误码率的增加，因此还需要进一步对协议进行优化。

4.2 协议优化

单纯提高吞吐性能无法解决误码率问题，因此还需要对协议进行优化、完善。

4.2.1 利用ACK字节确定拥塞窗口大小

TCP协议的拥塞控制对发送端设置了拥塞窗口（cwnd），其表示发送端在未经接收方反馈确认的情况下可发送的最大数据量。发送端根据cwnd的大小提供相应的硬件缓冲资源。增大cwnd，能够有效提升发送效率。同时，TCP通信中设置了确认字符（ACK），主要用于通知发送方已接收到数据。基于这一原理，将cwnd的确定方式修改为受限字节计数方式，即基于收到的受限的ACK字节数调整cwnd，通过该方式有约束地动态调整阻塞窗口的大小，能够在稳定安全的前提下降低丢包率，提升传输效率。

4.2.2 引入选择确认机制（SACK）

选择确认机制（SACK）是TCP协议针对失序数据包设计的一种确认机制。若TCP数据包按顺序收到，则接收方会返回ACK；若接收方收到的数据包并未按编号顺序，则接收方会返回SACK。发送方接到SACK后，可以通过自己的已发送数据包记录找到前序丢失的数据包，并补充发送。通过这一机制，系统能够在数据丢失的RTT内，自动进行检测和恢复。传统的确认机制是逐一确认，此次优化可利用选择确认机制，降低不必要的确认数据包，进而提升TCP的处理响应效率。

4.2.3 应用Lincoln链路层方案

Lincoln链路层方案是为了应对卫星信道动态切换问题而提出的。该方案通过对帧进行分块、选择和重组，改变了原有的稳定链路下的数据包转发逻辑。该方案下，数据信息得以快速获取，数据的恢复率和时效性大大提升，进而降低了重发重试比例，对于数据传输延时有明显的降低作用。同时，这一机制对于误码和丢失进行了应对，避免了数据拥塞。星链自身的特点是动态信道迁移，在这一场景下链路常常会发生变动，误码和丢失可能频发。通过Lincoln链路层方案对帧的特殊处理机制，可进一步降低数据传输延迟。

4.2.4 增加错误检测机制

传统TCP中对于链路拥塞错误并未分类处理，常规情况下就是重发重试。当遇到拥塞，往往动态降低窗口数，进而降低链路速率，缩短阻塞。然而拥塞原因较多，只有通过增加错误检测机制，对实际引发拥塞的机制进行排查，才能够有效应对错误[7]。

4.3 TCP Vegas算法优化

Vegas算法本身是一种拥塞评估算法。通过观测RTT值的变化，对网络链路拥塞情况进行评估，进而对网络进行适当调整。Vegas算法的关键参数有期望传输速率、实际传输速率以及实际传输带宽。式（4）表示了期望传输速率：

式中：RE表示期望速率，Wc(t)表示t时刻拥塞窗口大小cwnd，Tb为所观测到的链路中的最小往返时间（RTT）。式5表示了实际传输速率：

式中：RA表示实际速率，Tr为实际往返时间，Wc(t)表示t时刻拥塞窗口大小cwnd。式（6）则表示了实际传输带宽：

式中：Δ表示当前预估带宽。基于这一数据为基础来评估拥塞情况，并动态调整窗口，进而控制速率，平衡传输与拥塞。

然而，星链的动态性使得网络变化频率大大增加。以LEO卫星网络为例，传输距离始终随着距离变化而变动，这就使得RTT随时处于动态更新的状态。对极轨道星座而言，卫星之间高速的相互运动，以及卫星与极地之间的高速位置变化，使得网络拓扑结构有较高的变化频率，极端情况下每20 s就可能变动一次。上述情形使得通信延时显著增加[8]。

针对上述现状，本文提出对Vegas算法的优化方法。根据前文所述，因星链的特殊性，通信延时中传播延时是随机波动的，因此在降低延时的过程中，主要考虑从星上处理时延方面入手。对Vegas算法而言，只有通过对拥塞情况进行真实评估，才能够有效降低处理时延[9]。具体应对方案如下。

4.3.1 修改时间戳的功能与组成

新增进队列时间in_time、出队列时间out_time、节点处理时间node_time记录，以及最大节点处理时间max_node_time。这些信息需在原有TCP协议时间戳部分额外增加，长度共计16 bytes。

4.3.2 记录星上处理时延

当信息被传递到下一个星链节点时，下一个星链节点同样记录本次时间，并用本次处理时间对比最大处理时间。若本次时间大于最大处理时间，则替换该值。通过这一机制确保这里记录的是整个链路上节点处理的最大值。

4.3.3 可用带宽估算算法修改

星上处理时延数据通过ACK回传至发送端，即可获得真实的拥塞情况[10]。此时，原Vegas算法中的吞吐量评估算法需要进行修改。这里需要借助排队延时对吞吐量进行评估：定义S为星上缓存大小，定义Vr为发射速率，定义Tq为星上最大排队延时，则有：

此时，可由式（8）来评估当前的网络负载情况：

式中：Δ表示负载指数，Tpmax表示当前最大排队时延，Tq为星上最大排队延时。

根据该数据，进一步评估窗口调整算法，如式（9）所示：

式中：Wc(t)为t时刻的窗口大小。

4.4 优化效果评估

为对本次所设计的卫星宽带多媒体大容量低时延传输方法性能进行验证，利用仿真模型对吞吐、时延进行研究。

本次建立的实验仿真拓扑结构如图4所示。设置卫星缓存为50 packets，星上转发速率为10 Mb·s-1，星间链路与星地带宽为25 MHz和15 MHz。报文定义为200 bit，初始窗口设定为25。

图4 仿真拓扑结构

基于上述仿真环境，对本次所设计的TCP优化下的Vegas算法和传统Vegas算法分别进行仿真，可看到吞吐量和时延的显著变化，具体如图5所示。可以看到，优化的Vegas算法，其吞吐率可基本稳定在0.6左右，相比于传统Vegas算法频繁波动且低于0.2的平均吞吐率而言，优化的Vegas算法更加稳定。从表1可看出，两种算法的延时分布情况较显著，优化后的Vegas算法延时稳定在9～16 ms，而传统Vegas算法延时则在12～35 ms，大容量传输时延控制有效。

图5 仿真吞吐率

表1 算法仿真时延分布对比

5 结 语

本文围绕大容量多媒体数据在宽带卫星网络中的传输时延问题进行了研究，特别针对短时延传输方法提出对TCP协议进行优化，同时对于拥塞评估和处理算法Vegas进行优化。对于传媒行业而言，本文方法能够显著提升数据的传输性能，在无有线网络覆盖的区域能够获得高实时性的数据传输服务，进而提升媒体信息的时效性。本次所研究的相关方法能够进一步推广至其他卫星网络应用场景，使得宽带卫星网络的场景适应性更强。