深空通信网络体系结构及相关研究问题.doc

一， 深空通信网络结构IPN结构及各个部分的特点空间技术的发展使火星探测等深空科学任务成为了现实。未来的空间探测任务会需要在行星，月球，卫星，小行星，宇宙飞行器，和登陆车等之间进行通信。这些任务会产生大量的科学数据，这些数据需要高速可靠的在航天器之间传递并传送给地球。为了实现科学考察数据的有效传输和可靠的导航通信，NASA提出了发展下一代空间互联网体系结构，下一代的深空网络应该是深空星际网络的互联网，定义为星际互联网IPN(InterPlaNetary Network)。星际互联网可以提供科学考察数据的传输服务和未来深空探测任务的航天器与人造卫星的导航服务。星际互联网的可以提供的主要应用包括：l 时间不敏感的科考数据传输。实现从地外行星和月球收集到的大量科考数据在空间中的实体间互相通信。l 时间敏感的科考数据传输。将大量的本地视频和音频数据传输给地球，在轨机器人，甚至是在轨的宇航员。l 任务状态遥测数据传递。将任务，飞行器或登录器的状态和健康报告传输到指挥中心或其它结点上。这个应用需要一种周期性或事件驱动的不可靠的传输服务。l 指令和控制。另一种星际互联网的重要应用是对在轨单元的命令和控制。闭环命令和控制可以包括无线结点的直接或多跳通信，比如，地球基站控制在行星表面漫游的探测器，或者接近的结点，比如在行星轨道上控制登录器。目前的internet应用已经非常广泛，在internet技术的基础上构建空间互联网既可以节省开支又有高质量服务。因此，大多数深空探测用的网络结构都是基于internet技术的。NASA的空间互联网通用结构包括以下的结构单元：l 骨干网络。包括NASA的地面网络和空间网络，NASA的以太网和虚拟私有网络，因特网和商用或者国外的通信系统。l 接入网络。宇宙飞船和登陆车及其内部网络与骨干网的通信接口。l 宇宙飞船之间的网络。宇宙飞船的一个飞行编队或集群之间的网络。l 临近网络。在无线多跳自组织网络adhoc中分布的空间飞行器，登陆车，传感器等。空间因特网在被定义成因特网的网络，它用一个专用的长距离无线链路的深空骨干网络与因特网连接。因特网或者因特网相关的协议可以用来组成低延时，环绕地球的相对低噪音环境的，飞行器内部，环绕其它星球的网络等本地网络。在不同的环境中应该设计特殊的协议以适应特殊环境的限制。一个新的覆盖协议的概念称为“打包传递”，它将一些异构的因特网联系成一起，完成本地协议不能完成的功能。星际互联网结构如图1中表示，包括星际骨干网络，星际内部网络和行星网络。l 星际骨干网络。它提供地球，外部空间行星，月球，卫星和处于行星间引力稳定点上的中继站之间的一个通用通信设施。它包括长距离基本单元之间的数据链路（直接链路或多跳路径）。行星际骨干网络链路的最重要的特点如下述： 极长的传播延时。深空通信链路具有极端长的传播延时。长时延。例如:多数情况下低轨系统往返时延是40到50毫秒，中轨系统是120到260毫秒，地球同步卫星轨道大约550毫秒，并且还受到星间路由选择、星上处理以及缓存等因素的影响。而在星际骨干网中往返时延更高。例如:从地球到火星的距离在6000万公里以上，传输的往返时延从8到40分钟之间，其它如木星和冥王星到地球的RTT范围分别是81. 6到133. 3分钟和593. 3到1044. 4分钟之间。 高链路误码率。现有的卫星信道误码率(Bit Error Ratios, BER)大约是10-6,最坏情况为10-4。在骨干网误码率更高，例如月球距地球约38万公里,而其它行星距地球都在几千万公里以上。由于距离远，使信号衰减造成信噪比降低，另外，某些行星存在的电磁辐射引起的干扰，使信噪比进一步下降，导致BER一般只能达到10-1数量级。 链路暂时中断。因为行星的运动，小行星或者宇宙飞船的干涉造成的光线的不可见，周期性的链路中断很可能发生。 不对称带宽。在一般情况下，前向和反向信道带宽容量之比约为1000:1。在某些情况下，甚至是单向通信.l 行星际外部网络。他包括在行星见的深空飞行的宇宙飞船，传感器结点群，空间站群等。一些行星际外部网络的结点还拥有远距离通信的能力。l 行星网络。包括行星卫星网络和行星表面网络。如图2中所描述。这种体系结构可以在所有外部空间行星上实现，提供了行星的卫星和地面之间的互连接和互操作。 行星卫星网络。环绕行星飞行的卫星可以在地球和外部空间行星之间的中继服务，同样也为行星表面的单元进行通信和导航服务【55】。一些行星表面单位有跟卫星通信的能力，报告本地地形结构，从卫星接收指令和数据。行星卫星网络包括环行卫星之间的链路，卫星和地面单元之间的链路。它包括图2中所述的多个层次，提供如下服务：地球和行星之间的存储和中继服务，执行任务的单元之间的中继服务和行星表面网络的位置管理。 行星表面网络。它提供了漫游者和登陆车等行星表面单元之间的通信服务，他们可以与卫星进行连接。他们还提供了行星表面的能力稳定的无线骨干网络。此外，行星表面网络还包括不能直接与卫星通信的行星表面单元。这些单元一般是由传感器和气球等，以集群方式分散分布组成一个无线多跳自组织网络。如图2示。目前，空间站和卫星已经部署了，可以很容易的整合到星际骨干网络中去。同时，在不远的将来，未来科学研究在深空中部署的传感器结点就可以连接到星际骨干网络上。根据【9】的说法，为火星表面探测任务计划好的一些科学设备是为了深空探测的传感器结点。这些设备可以根据星际网络的结构进行组织。这些设备所处的探测区域被称为部落区域。在每个部落区域中都可以建立星际表面网络。总的来说，图1和2描述的行星际因特网体系结构是被分解成了不同的子网。每个子网面临不同的挑战，有自己特点的要求。因此需要有一个通用的协议栈来将不同的部分整合起来，将陆地上的因特网连接到星际互联网中。同时，它也给开发适应每个子网特殊环境的协议留下了很大的空间。二， CCSDS和DTN Bundle三， 传输层l 传输层的功能对于行星际因特网科考数据的可靠传输和多媒体信息的及时传递都是必要的。在图1中所示的行星际因特网的结构体系元素中，行星际骨干网络是可靠传输和多媒体传输的最大困难，它对整个行星际因特网的表现起着重要作用。现有的为陆地，卫星，无线和多跳自组织网络的传输层协议可以通过一些适当的修改使其应用在图1示的行星际外部网络和行星网络中。然而，行星际因特网面临的挑战需要特别制定的新的传输层协议来解决。4.1 行星际骨干网络的可靠数据传输4.11 相关工作实现行星际因特网满足深空任务通信的需求，现有的可靠传输协议在深空通信网络的表现都很差。造成这种性能降低的主要原因就是深空链路的极高的延时。这是因为目前TCP协议在慢启动和拥塞避免算法中使用的基于窗口的机制。在慢启动算法中，拥塞窗口大小(W)直到慢启动阈值(WSS)之前，每收到一个ACK增加一，此时W WSS。然而，这种方式持续很长时间浪费带宽，持续时间与传播延时成正比。如果WSS =20，RTT=20分钟，慢启动在120分钟内都不能完全的使用全部带宽。这种低效率的利用链路带宽的基于窗口的机制在慢启动算法中也存在，此时WWSS。TCP的源端每一个RTT时间才增加1.如图6所示，目前的基于窗口的TCP协议在链路带宽为1MB/s，丢包率p=10-3,RTT=40分钟时，只能达到10byte/s的吞吐量。换句话说，在连接建立阶段，整个深空链路基本上没有被利用。注意到RTT=40是地球和火星的通信链路的RTT范围之内的，基于所处轨道位置，约8.5-40分钟。此外，目前的TCP协议是针对有线链路设计的，假定误码率是可忽略的。因此，基于丢包的拥塞探测机制就造成了无谓的速率瓶颈并导致在行星际骨干网络中严重的吞吐量降低。近几年为了解决在无线链路错误造成的吞吐量降低做了很多研究工作。然而，这些解决方案不能直接应用于行星际骨干网络，原因是极高的传播延时和前面所述的特性放大了问题的影响。基于卫星链路提出了很多传输层协议，卫星链路也有高带宽延时积和高误码率。不过，这些研究几乎都是对于地球同步轨道GEO卫星链路的，典型的RTT大概是550ms,相对与深空通信链路的RTT小的很多。此外，由于链路中断造成的丢包也同样会误导基于丢包的拥塞控制机制。在【53】，开发了为解决因为移动而导致的信号丢失的对TCP的扩展。然后，深空链路中的链路中断的情形由于极高的传播延时而更加复杂，因此【53】中的解决方案并不能直接应用。行星际因特网传输协议还面临很多别的挑战需要去解决。如下：l 延迟的反馈。TCP期望对链路状态做出反应。这种期望在长延时环境中造成了问题，因为TCP使用端到端的信号作为它的控制回路。RTT越长，源端接收到的关于链路状态的信息就越晚。因此，基于这样过去时的信息的拥塞控制机制可能不会导致正确的行为。因此对瞬时丢包情况做出反应的拥塞控制机制不会在大延时链路中作出合适的反应。l 缓冲区大小。为了保证100%的可靠传输，重传机制是不可避免的。然而，这就带来了可观的内存容量的要求。例如，传输协议需要为RTT=20和平均发送速率为1MB/s的链路准备1.2GB的缓存。现在对深空背景通信网络传输层协议的研究已经很活跃。Space Communications Protocol Standards-Transport Protocol(SCPS-TP)是CCSDS为了深空通信而开发的TCP的扩展集合。SCPS-TP是为了满足目前的通信环境和将来的空间任务而设计的。SCPS-TP是对目前的TCP协议进行一些修改和扩充来解决深空通信中的链路错误，不对称带宽和不持续连接等问题的。它可以根据任务的通信需求提供完整的，尽全力的最小限度的可靠性。SCPS-TP的能力基本上是目前TCP协议的结合体，而TCP已经显示并不能满足星级骨干网络的要求。例如，使用Vegas拥塞控制的SCPS-TP使用基于窗口的机制和使用了慢启动算法。尽管使用基于速率的SCPS-TP正在开发当中，它不使用拥塞控制机制，通过用户选择的固定速率发送数据。另一方面，SCPS-TP使用TCP-Vegas使用基于RTT变化的拥塞决定机制。然而，因为TCP-Vegas的基于窗口的本质，它不能够完全的使用链路带宽，因为变化的RTT，它也不能感知拥塞。因此，基于RTT的变化的拥塞避免机制并不能提供很好的拥塞控制功能。此外，由于极高的延时，RTT的变化并不能精确的衡量，因此作为结果，拥塞控制行为也可能不精确。在【29】，CFDP也是用CCSDS开发的。这个协议可以在深空链路中达到可靠的文件传输。然而，它也不能解决如上的困难，它也不是一个拥有在行星际因特网实现高数据速率可靠传输功能的传输层协议。在【94】，介绍了包裹协议来解决不连续连接，大而可变的延迟和高误码率。如图4所示，包裹层协议在应用层和底层协议之间，在延时可容忍网络中表现为一个基于保管的存储和转发方式。此外，这种方法中间路由器有很大的存储空间来储存数据。需要的存储空间大小随着链路延时的变大和发送数据速率的变快而增大。而且，如此巨大的缓存也需要有效和快速的缓存管理机制来防止传输被存储转发机制所影响。基于包裹层的存储和转发机制，DTN方法结合了捆绑的ARQ和捆绑的拥塞控制概念通过本地重传和在区域内拥塞控制来提供可靠传输，也就是在本地节点之间而不是端到端之间进行可靠和拥塞控制。尽管这种方法可以在不连续连接的链路上实现可靠传输，它还需要一个传输层协议，也是为了解决同样的挑战，在两个行星际因特网节点之间达到高吞吐量的包裹传输。在【45】，介绍了长距离传输协议(LTP)在包裹节点之间来传输包裹。LTP是目前正在开发中的协议，在【113】中描述，作为一个链路层的ARQ添加一些相关的CFDP文件传输协议的功能，而不是类似于TCP的传输协议。4.1.2 TP-Planet在【2】中，介绍了一个行星际因特网的传输协议，TP-Planet。TP-Planet是为了行星际骨干网络而开发的，源端和接收器节点基本上都是行星际骨干网络的节点，比如环绕行星的中继卫星或者有直接深空通信能力的地面站。它在因特网协议层IP之上，不需要对目前TCP/IP协议簇底层协议做任何修改。TP-Planet可以作为传输层协议使用在现行CCSDS协议栈和DTN包裹协议栈中。TP-Planet协议主要由初始状态和稳定状态两个新算法组成。1. 初始状态。为了避免慢启动算法对性能的影响，TP-Planet的初始状态算法，包括两个主要部分，直接启动和跟随增加。目的就是在可控制的形式下尽可能快的获取可用链路资源。2. 新的基于速率的适应AIMD机制。基于速率的拥塞控制机制相对于基于窗口的机制对于过大的延时有更大的鲁棒性。3. 新的拥塞控制。为了解决由于行星际骨干链路高误码率而导致的性能降低，TP-Planet在稳定状态实施了一个新的拥塞探测和控制算法。TP-Planet源端同事发出低和高优先级的NIX段，比数据包要小，40字节。假定通路上的路由器都可以根据优先级排队，低优先级NIX段的高丢失率就可以认为是拥塞的信号。节点接收器周期性的发回低优先级的Nlow和高优先级的NHigh接受到的数目。他们的比率=（Nlow/NHigh）由预先设定的阈值来测试，i和d，之后数据传输速率S通过图7来增加或减少。【2】4. 暂时中断状态。为了减少暂时中断的情况对吞吐量的影响，TP-Planet在协议行为中加入了了暂时中断状态程序。暂时中断行为可以在【2】中看到。为了提供可靠传输，SACK选项被TP-Planet用了应对突发的丢包。因为可能在很长的中断状态期间SACK选项域的SACK块的数目不够，TP-Planet还包括了超时机制。5. 延时的SACK。为了解决行星际骨干链路中不对称带宽的问题，TP-Planet使用了延时SACK的机制，降低了反向信道的流量，避免在反向信道上发生拥塞。在这个机制中，源端用一个延时因子d来控制发送SACK包。当出现一个新的丢包时，接收方立即发送SACK包。以这种方式，TP-Planet可以在行星际骨干链路上控制反向信道的流量。如【2】示，通过仿真实验，TP-Planet在行星际骨干链路中提供了高的吞吐量表现解决了问题。42行星际骨干网络中的多媒体传输除了可靠传输数据，多媒体流量也是行星际因特网的总体流量的一部分【9】。一些声音和可视化信息包括行星图像和科学观察资料等也会通过这些链路传输。多媒体流量不需要100%的可靠，但是对迟变异，最小带宽和传输速率的迅速变化有很严格的要求。多媒体英语通常被分为两类：实时的或存储的多媒体流和实时的交互多媒体。明显的，实时交互多媒体因为极端长的传播延时是不可能在行星际因特网骨干链路上传输的。然而，实时的或存储的多媒体流可以作为一部分流量在空间链路上传输。对多媒体流量的控制是一个棘手的问题，因为不受控的多媒体流量不但会拥塞网络，还会对其它数据传输造成不公平现象。4.2.1挑战除了4章中提到的再行星际骨干网络中可靠传输的挑战之外，多媒体传输还面临其它的挑战。如下所述：l 迟变异。数据包遇到的端到端的延时的变化被称为迟变异。多媒体流量对迟变异有很严格的要求，因为延时的抖动可以在重组多媒体信息时产生问题。这个挑战一般是通过在接收端使用一个缓存来解决的。l 最小带宽。大部分多媒体应用为了达到最小的媒体感知质量要求最小带宽。如果带宽降到阈值以下，接收的媒体就不能被正确的察觉出来。l 平滑的流量。媒体速率的中断和频繁的波动可以造成接收媒体质量的大幅降低。因此，多媒体传输协议的主要目标就不是主动的发现和使用带宽，而是维持一个相对稳定的媒体速率同时对拥塞作出反应。l 错误控制。在行星际因特网传输的多媒体流量可以被编码成MPEG，动态JPEG或者H.26x。尽管错误恢复技术可以在视频流中使用，压缩的视频流还是对数据丢失很敏感。4.2.2 相关工作很多多媒体传输协议是为了在陆地网络中控制多媒体流量而提出的【17，52，54，77，89，90，100】。这些提出的协议可以大体上分成两种类型的控制机制，基于AIMD的和基于方程的？基于AIMD的速率控制机制是对TCP兼容的，基于反馈信息保守的调整发送速率，相对公平的竞争。流控制协议SCP是TCP的修改版本，使用类似TCP-Vegas速率调整算法。TCP接收端模拟TEAR【90】，使用数据包到来，数据包丢失和超时等信号来决定接收方的接收速率。使用这些信号，TEAR在接受端模拟了包裹慢启动，快速回复和拥塞避免的TCP流量控制功能。速率适应协议RAP【89】是一个在有线和短距离网络中基于速率的控制机制。速率控制机制RCS100是在高带宽延时积和有损链路中的实时流量的速率控制机制。然而，所有这些现存的基于AIMD的速率控制机制都是基于传播延时相对短的假设，这并不适合于行星际骨干网络链路。此外，AIMD机制造成了在锯齿模式中媒体速率的中断和频繁的波动，这对于大多数的多媒体应用来说都是不适用的。基于程序的速率控制机制是在陆地网络中为了提供相对平滑的多媒体流量传输而提出的。基于程序的拥塞控制的想法是在TCP对应的双方经历同样的丢包率，往返时间和数据包大小时调整发送速率而不是吞吐量。TCP友好速率控制TFRC是一个在拥塞控制机制使用了简单TCP吞吐量模型的基于程序的速率控制机制。MPEG-TFRCP【77】是另一个用来以一个TCP友好方式传输MPEG-2视频基于程序的速率控制机制。不像TFRC,TFRCP在调整视频速率时特别的将视频的特性考虑进来。尽管使用TCP相应功能确保了基于方程的控制机制与TCP长时间范围内的公平竞争，稳定状态下的TCP源端吞吐量模型还是对RTT非常敏感。因此，基于方程的速率控制机制也不能达到很高的链路利用率而且一次并不是在高传播延时的行星际骨干网络链路上很好的解决办法。SCPS基于速率的协议是为了深空通信而提出的。然而，协议中没有包含任何的拥塞控制算法。SCPS基于速率的协议源端的传输速率是由用户和接收端的缓存大小限制决定的。换句话说，SCPS基于速率的协议不能根据网络状况调整发送速率。因此，如果发送速率大于可用带宽，它就可能在行星际骨干网络链路上造成拥塞。除了上面提到的速率控制机制，为了在陆地网络上最小化视频质量的变化提出了层次化的方法。很大普遍使用的压缩标准，比如MPEG-W,MPEG-4和H.263，都对层次化编码有扩充。使用层次化的编码，源端可以实现一个层次化的编码流，一个基本层和多个加强层。速率控制在增加的或放弃增加的层中实现。如果可以使用更大的带宽，更多的加强层可以用来改善视频的质量。另一方面，如果链路带宽降低，一下加强层可以被放弃。在层次化的方式中，它要求所有的底层可以被正确的接受。在行星际因特网链路中，这样的要求常常得不到满足。此外，相对于不分层的方式，分层的方式也会造成很大的压缩损失。因为这个原因，分层的方式并不适合于行星际因特网。图4中描述的包裹协议，是深空通信中在传输层之上的【13，19】。如在4.1节所说，包裹协议的基本想法就是以一种存储和转发的模式运行。然而，多媒体流量对时间有很严格的要求，在一个指定点指定时间之后接收到的数据就没用了。因此，存储和转发方式对于多媒体数据来说是不合适的。此外，中间路由器需要以存储和转发的模式缓存数据，这会要求固定的存储空间。假设一跳的RTT值为20分钟，平均传输速率时1MBps，则路由器需要在它的缓存中保留1.2GB的空间。如果平均传输速率和RTT更大，需要的缓冲空间将更大。对于如此巨大的缓冲空间，对缓冲的操作要花很长的时间。结果，包裹协议并不适合于在行星际因特网中对于多媒体流量的速率控制。包路径分散机制是为了在因特网上进行实时语音通信，在延时，数据丢失率和通话质量之间折中而提出的一种机制。不在一个网络通路中严格控制传输，而是在多个不同的不相关的通路上传输冗余的语音流信息，利用了不同链路之间不相关的丢包和延时特性。然而，因为行星际骨干网络链路主要是点到点的链路，不太可能在不相关的链路上传输多个多媒体流。因此，这个机制对于行星际因特网也不可行。另一方面，尽管多媒体流量本身就具有容错性，为了在现存的高误码率链路上维持一定的成功概率，还是需要差错控制机制。然而，因为极高的传播延时，基于重传的ARQ机制还不能为了这个目的而在行星际骨干网络链路中使用。因此，数据包级的前向错误纠正机制FEC【83】可以使用在行星际因特网中。这种使用数据包级的多媒体传输的FEC的一个重要参数就是它的编码和解码的时间。传统的FEC机制比如Reed-Solomon编码对于大的FEC数据块有很慢的编码和解码时间，这将数据块的大小限制得很小。结果是使FEC的冗余代价增加，这是在行星际因特网珍贵的通信资源中应该避免的。另一方面，Tornado编码【15】是基于随机二部图和异或操作的，这让Tornado编码在大规模数据上比标准的擦除性编码运算更快。因此，Tornado编码适合在行星际骨干网络链路上的FEC数据块大小数据包级别的FEC。尽管Tornado编码需要稍微多一点的编码包来重建原始数据，因为较小的FEC开销，这个缺点是可以被大的FEC数据块所补偿。因此，目前的速率控制机制不能解决行星因特网骨干网络的困难。应该提出适用于行星际因特网的新的多媒体传输协议。4.2.3 RCP-PlanetRCP-Planet【49】，一个速率控制机制，是为了解决如图1示的源端和目的结点都基本上是环绕行星的中继卫星的行星际骨干网络的多媒体传输的困难而提出的。RCP-Planet运行在IP层，不需要对底层的TCP/IP协议簇做任何修改。RCP-Planet包括两个状态，初始状态和稳定状态，如图8所示。RCP-Planet的主要功能如下：1. 数据包级别FEC。为了恢复由于在行星际因特网中链路错误或者拥塞引起的数据包丢失，使用了Tornado编码来进行数据包级别的FEC，原因是它很快的编码和解码速度。尽管Tornado编码要求略微稍微rnado多的编码包来重建原始数据，由于比较小的FEC开销，这个缺点还是可以通过大的FEC块来补偿的。此外，Tornado编码只使用异或运算，这是他们更好实现。FEC块的大小根据不同的数据包丢失率来选择，以使FEC开销最小。2. 初始状态。在初始状态，因为在开始时得不到任何链路信息，很难判断初始的发送速率。保守的，我们设置初始多媒体速率为应用程序要求的最小值来避免向网络中发送过多的数据包。因为初始状态的丢包率也是未知的，最近的历史值pn作为目前丢包率的近似值来觉得FEC块的长度n。然而，实际的丢包率可能不会是pn。为了应对最坏的网络状况我们保守的选择一个比pn大得多的丢包率p1作为更坏的网络状态来计算相应的FEC块的长度n，n是作为实际的FEC块的长度来对数据进行编码的。因为n-n的冗余数据包是对解决更坏情况的附加冗余，他们以低优先级发送。低优先级的包在拥塞时不会对正常的流量产生影响。剩下的n个数据包以高优先级发送。3. 新的速率探测机制。速率探测是为了测量接收端的速率来决定可用带宽的机制。这个新的速率探测机制在每个FEC块中实现，在每个FEC块中，一定数量的被称为探测序列的数据包以一个称为探测速率rp的高速率发出。FEC块中剩下的包使用目前的源端发送速率rs。一些探测包可以因为网络带宽的限制被被网关丢弃，接收端探测序列的观察速率ro是可用带宽。探测序列的长度是一个设计参数并可以适当的选择。另外一个设定参数是探测速率rp。在初始化状态，不能得到任何关于链路状态的信息，因此rp被以一种可以尽快获取可用带宽的方式设置。在稳定状态，探测速率根据网络状态而更新。4. 新的速率控制机制。为了平滑的传输多媒体信息，RCP-Planet实施了一个基于速率探测机制的新的速率控制机制。在从接收方收到ACK之上，当前的观察速率ro可知，这显示了可用带宽。相对的可用的媒体带宽ra可以从ro算出，这是当前媒体速率的上界。如果rarm，此时rm是当前的媒体速率，网络带宽并没有完全使用，可以增加媒体速率。多出的数量（ra- rm）每个平滑线性的RTT增加1，为的是减少网络出现拥塞的机会。另一方面如果ra rm，当前的媒体速率过高，发送端需要回退并减少它的媒体速率，因此媒体速率乘法降低。5. 暂时中断状态。为了减少因为暂时中断对吞吐量降低的影响，RCP-Planet在协议中加入了暂时中断状态。发送端如果在一段时间内收不到任何ACK，就推断为暂时中断并停止发送任何数据包。类似的，接收方也会推断暂时中断并开始发送称为Zero的ACK。因为RTT非常大，暂时中断对性能的影响根据发生暂时中断的位置有关。Zero ACK和当暂时中断时在传输过程中的ACK被发送方用来根据暂时中断情况获取准确信息和正确行动的标准。6. FEC数据块级别的ACK。为了解决在行星际骨干链路中的不对称带宽的问题，