A Study of DTN for Reliable Data Delivery from Space Station to Ground Station

abstract

— 延迟/中断容忍网络 (DTN) 是一种网络技术，旨在管理没有一致的端到端链路连接的机会性连接，这在地面和太空通信环境中很常见。 DTN 被认为是实现深空网络的基线技术。 Licklider 传输协议 (LTP) 被视为太空中 DTN 的主要传输协议，无论是否存在随机链路中断和/或极长的传播延迟，都有望在充满挑战的网络环境中提供可靠的数据传输服务。美国国家航空航天局 (NASA) 已在国际空间站 (ISS) 上使用 DTN 协议向地球地面站传输数据。然而，在研究 LTP 在这种通信环境中可靠的数据/文件传输的性能方面所做的工作还很少，特别是在存在链路中断的情况下。 LTP 在空间站通信中的应用缺乏可靠的性能评估。本文提出了一个分析框架来评估 LTP 在空间站和地面站之间可靠文件传输的性能，重点关注可能发生在下行链路或上行链路上的链路中断的影响。还集成了由于通道错误导致的数据丢失的影响。使用基于 PC 的实验基础设施进行真实的数据块传输实验，以验证分析模型。

introduction

人们普遍认为，极长的信号传播延迟、长时间且频繁的链路中断、高数据丢失率和高度不对称的信道速率是降低深空链路数据传输性能的主要因素。延迟/中断容忍网络 (DTN) [1] 是作为实现星际深空网络 [2] 的基线网络技术而开发的。作为DTN协议栈的核心“叠加”协议，捆绑协议（BP）[3]旨在为DTN中基于托管的数据传输服务构建“存储转发”叠加网络。 BP 通过调用称为“汇聚层适配器”（CLA）的接口服务来利用底层网络的传输协议。 CLA 反过来在所谓的“汇聚层”上运行底层数据传输协议栈。

针对太空中 DTN 的主要传输协议，Licklider 传输协议 (LTP) [4]、[5] 预计能够在具有挑战性的网络环境中提供可靠的数据传输，无论是否存在随机链路中断和/或极长的传播延迟。与普遍使用的传输控制协议（TCP）一样，LTP 实现基于自动重复请求（ARQ）的重传方案。然而，LTP以连续的方式实现其基本协议数据单元protocol data units（PDU）（即块）的多个并发传输[5]，而不需要等待确认（ACK）。此外，为了满足各种应用需求，LTP还提供了选择性的数据传输服务：用户可以选择TCP类型的可靠传送服务或UDP类型的不可靠传送服务。

虽然DTN的最初意图主要是针对链路时延极长的深空通信，但当链路时延不是很长时，DTN协议也因其对频繁或随机间歇性链路连接的场景的有效容忍而受到业界的广泛认可。 ，甚至通过地面链路。这种应用的一个典型例子是从国际空间站（ISS）到地面站的可靠数据传输[6]，因为地面站的数量和位置无法保证天地连续链路连通。在国际空间站通信中，由于地面站数量不足，不可能与地面站持续直接联系。因此，主空间站通信系统被设计为基于中继的架构——数据下行链路路径通过在更高的地球静止轨道（GEO）上运行的高带宽弯管卫星进行中继[7]。即使采用基于中继的架构，中继卫星联系窗口之间也可能存在连接故障。此外，由于大气和太阳天气事件等因素，也可能随机发生链路中断。

在卫星和空间网络的研究和开发方面已经开展了大量工作[8]-[12]。在将 DTN 概念应用于偏远地区连接和监视方面已经开展了一些工作，其中一些工作采用了纳米卫星和基于 WiFi 的无人机 [13]、[14]。 [15] 中介绍了卫星 DTN 的研究，重点关注基于卫星的网络场景。在这些场景中，无论是单播还是组播卫星通信场景，DTN的采用都显着提高了数据传输效率。然而，由于通信环境的差异，这些研究的大多数结果并不适用于国际空间站通信中可靠的文件/数据传输。

作为一种基于 UDP 的多路复用和安全传输协议，快速 UDP 互联网协议 (QUIC) [16] 引起了互联网社区的广泛关注。 QUIC 为结构化通信和快速连接建立提供流量控制流的传输服务。它已被考虑用于包括卫星通信在内的广泛应用。 QUIC 作为空间站和卫星通信在链路中断时的可能解决方案的性能评估正在进行中。

NASA喷气推进实验室（JPL）和其他学术团体联合做出了一些努力，在空间网络中运用DTN协议，包括BP[17]-[27]及其主要传输协议LTP[28]-[35]。然而，在大多数 LTP 研究中，链路中断的影响要么被忽略，要么被假定为传输时间的恒定偏移，即，链路中断持续时间只是简单地添加到总文件/数据传输时间中，而没有进行详细分析它如何真正影响数据块交付和传输性能。此外，简单地将中断持续时间添加到基线交付时间是块交付时间的非常粗略的近似值，这可能无法准确地表征 LTP 的性能。在[35]中，提出了火星通信中 LTP 的单链路中断事件影响的理论框架。

NASA 已在国际空间站上使用 DTN 协议将数据传输到地球地面站 [6]。文章 [36] 中还介绍了使用基于 PC 的测试台基础设施收集的一些初步实验结果，这些结果涉及 LTP 在链路中断的情况下从空间站到地面站可靠传输数据的性能。

然而，在分析 LTP 从空间站到地面站的可靠数据/文件传输的性能方面，特别是在存在链路中断的情况下，很少进行分析/建模工作。需要一个分析框架来对 LTP 进行可靠的性能评估，以实现空间站和地面站之间可靠的文件传输。

An Analytical Framework for Disruption of Licklider Transmission Protocol in Mars Communications

abstract

作为延迟/中断容忍网络（DTN）的主要数据传输协议之一，Licklider 传输协议（LTP）旨在在以频繁且长时间的链路中断和极长的信号传播为特征的星际互联网环境中提供可靠的数据传输延误。人们已经对 LTP 在地月和火星通信中的性能进行了一些研究。然而，迄今为止，链路中断对火星通信 LTP 的影响很少受到关注。本文提出了一个分析框架，用于分析链路中断对火星通信中 LTP 可靠数据传输和性能的影响。该分析重点关注各种链路中断如何影响传输尝试次数、随后的数据交换往返时间 (RTT)，以及在火星通信中实现可靠数据块传输的 LTP 良好输出性能。该分析框架通过使用基于 PC 的实验基础设施进行的实际数据块传输实验进行了验证，并且可用于预测在存在链路中断的情况下深空飞行器通信通道上的 LTP 性能。

本文贡献

在之前类似的 LTP 研究中，假设链路中断对传输性能具有不变的影响，即中断持续时间只需添加到总文件/数据传输时间中。本文研究了链路中断对LTP的影响，对随机起始时间和任意持续时间的链路中断进行了具体分析。提出了一个分析框架，用于分析随机链路中断对火星通信中 LTP 可靠数据传输和性能的影响。该研究重点分析各种链路中断如何影响传输尝试次数以及随后的数据交换往返时间 (RTT) ，以及由此产生的 LTP 可靠数据块传输的良好输出性能。该框架通过使用基于 PC 的实验测试台基础设施的实际数据块传输实验进行了验证。

据我们所知，本文提出了该问题的第一个分析框架，并结合了链路中断对火星通信中 LTP 可靠数据传输影响的实验结果。该框架对于表征链路中断时 LTP 的操作和传输性能非常有用。使用分析和实验方法收集的定量结果预计将有助于协议配置和 LTP 的优化设计，以便在未来的火星和其他深空飞行任务中实现高度可靠和高效的数据传输。

OVERVIEW OF RELIABLE DATA TRANSMISSION OF LTP

如所讨论的，LTP可以被配置为通过将块（全部或部分）配置为“红色”部分和/或“绿色”部分来向数据块提供可靠传输服务和/或不可靠传输服务。对于设置为红色的新块的传输，在接收到来自客户端服务的块传输请求时，发送方根据底层链路最大传输单元（MTU）大小将块分割为多个红色LTP数据段以进行传输。发送方将最后一个数据段标记为异步检查点（CP）、红色部分结束（EORP）和块结束（EOB）[5]。 CP 定时器在排队的 CP 段被传输后启动。

可以从LTP接收器接收报告段(RS)，请求重传未成功接收的数据段。如果 RS 指示数据块接收不完整（即，由于任何原因导致数据丢失），LTP 发送方将重新传输丢失的数据段。这些丢失的分段中的最后一个将作为 CP 重新传输。否则，如果RS指示成功接收到所有红色数据，则LTP发送方通过发送报告确认(RA)段来确认它。另一个中断 LTP 发送方的事件是先前设置的 CP 定时器到期 [4]。在这种情况下，需要重新启动CP段并启动新的定时器，并且LTP发送方返回到中断状态。

继上面对LTP可靠传输机制的简单描述之后，图1比较了“红色”数据块的LTP传输的两种场景。由于本研究主要关注链路中断的影响，因此场景适用于没有链路中断的传输（即图 1(a)）或经历过链路中断的传输（即图 1(b)）。为了简单起见，示出了每个块仅被分段为四个段以进行传输。

对于图1（a）中没有链路中断的LTP一般传输场景，交互传输过程遵循上述流程和算法。块的所有分段均以连续方式传输，最后一个分段标记为 CP/EORP/EOB。假设没有发生链路中断和信道错误，传输过程中不会发生数据丢失，并且所有数据段都在接收器处成功接收。然后，接收器发送 RS 以确认 CP 段和整个块的成功接收。作为响应，发送方向接收方发送 RA，从而结束整个块的传输。

对于图1（b）中存在链路中断的情况，与图1（a）中的情况类似，块的所有四个段都以连续方式传输。 CP 定时器在 CP 段被发送时启动。然而，最后一个段（即CP段）在传输过程中遇到链路中断并丢失。换句话说，由于链路中断，同步CP段没有在接收器处传送，因此，不应期望其相应的RS段到达发送器。

请注意，在链路中断期间，当先前设置的 CP 定时器到期时，将重新发送 CP 段。根据链路中断的持续时间，CP 段可能会重新发送多次，直到感知到链路已恢复。因此，链路中断事件对总块传送时间的时间贡献可以简单地估计为CP定时器长度和发送次数的乘积。

一旦数据链路恢复，最后重新发送的 CP 段就会成功传送到接收器。随着 CP 段成功传送，该块的所有四个段都被接收器成功接收。作为响应，接收器发送 RS，确认接收到先前发送的 CP 段。假设 RS 在发送方成功传递，它可以向发送方指示整个块已成功传递。然后，发送方发送 RA 作为响应，标志着块传输的结束，如图 1（a）所示。

链路中断对 LTP 影响的分析模型

本节介绍了链路中断对火星通信 LTP 影响的分析模型。表 I 列出了建模过程中使用的符号。这些模型是基于我们之前的工作 [20] 中开发的空间通信中 LTP 运行的系统模型构建的。

请注意，通道误差对 LTP 的影响已得到广泛研究 [21]、[23]、[25] 和 [29]。如果本研究中也考虑信道错误的影响，那么除了单独分析每个因素的影响之外，还需要仔细分析链路中断和信道错误的相互作用。这将使分析变得更加复杂；这项研究超出了本文的范围。为了准确分析链路中断对 LTP 的影响，本研究忽略了信道错误的影响；也就是说，假设所有数据丢失以及由此产生的额外文件传送时间都是由于链路中断事件导致数据链路不可用而发生的。

令ΔRTTDisrupt表示链路中断对LTP数据块传送的时间影响，即链路中断导致的RTT增量。这个效应可以写成

$$\Delta RT{T}_{\text{Disrupt }}=RTT-RT{T}_0$$

其中RTT是在存在链路中断的情况下LTP块传送的估计RTT，并且RTT0是在不存在链路中断的情况下LTP块传送的基线RTT。

[20]中提出的系统模型主要是为了估计LTP的RTT而建立的，这里重新回顾一下

Q. Yu et al., “Modeling RTT for DTN protocols over asymmetric cislunar
space channels,” IEEE Syst. J., vol. 10, no. 2, pp. 556–567, Jun. 2016.

$$\begin{array}{rl}RTT=& 2\times T_{OWLT}+T_{\text{Block }}+T_{RS}+\Delta RT{T}_{\text{Disrupt }}\\ =& 2\times T_{\text{OWLT }}+\frac{\left(L_{\text{Seg }}+L_{\text{Frame-Head }}\right)}{R_{\text{Data }}}\\ & \times \lceil \frac{N_{\text{Bundle }}\times \left(L_{\text{Bundle }}+L_{\text{Bundle-Head }}\right)}{L_{\text{Seg }}}\rceil \\ & +\frac{L_{RS}}{R_{ACK}}+\Delta RT{T}_{\text{Disrupt }}\end{array}$$

这段代码描述了LTP（Licklider Transmission Protocol）协议中往返时延（$RTT$）的计算方式。LTP是一种用于延迟容忍型网络的协议，通常用于对抗高延迟、不可靠、带宽有限的网络环境，比如深空通信。

具体来说，这段代码中的符号表示了以下内容：

• $RTT$：往返时延
• $T_{OWLT}$：单向链路传输时延（One-Way Link Transmission Time）
• $T_{Block}$：块处理时延
• $T_{RS}$：接收段（Receiver Segment）处理时延
• $\Delta RT{T}_{Disrupt}$：$RTT$中的中断时间
• $L_{Seg}$：分段长度
• $L_{Frame-Head}$：帧头长度
• $R_{Data}$：数据传输速率
• $N_{Bundle}$：捆绑数
• $L_{Bundle}$：捆绑长度
• $L_{Bundle-Head}$：捆绑头部长度
• $R_{ACK}$：ACK（确认应答）传输速率
• $L_{RS}$：接收段长度

这段代码的目的是计算从发送到接收并收到确认应答所需的总时延。

以下是前面关于公式计算细节的对话，使用了$A$格式表示数学字符：

好的，让我来解释一下这个公式中的计算细节。

1. 单向链路传输时延 ($T_{OWLT}$)：
   这个时延是指从发送端发送数据到接收端接收到数据所需的时间。它可以通过数据的大小除以发送速率来计算。公式中表示为$T_{OWLT}=\frac{L_{Seg}+L_{Frame-Head}}{R_{Data}}$，其中$L_{Seg}$是数据分段的长度，$L_{Frame-Head}$是帧头的长度，$R_{Data}$是数据传输速率。

2. 数据段分段及捆绑影响：
   数据段可能会被分段，并且多个数据段可能会被捆绑在一起传输，这可能会影响传输时延。具体地，分段后的数据段数量为$\lceil \frac{N_{Bundle}\times (L_{Bundle}+L_{Bundle-Head})}{L_{Seg}}\rceil$，其中$N_{Bundle}$是捆绑数，$L_{Bundle}$是捆绑长度，$L_{Bundle-Head}$是捆绑头部长度。

3. 接收段处理时延 ($T_{RS}$)：
   这个时延是指接收端处理数据段的时间，包括接收数据、解析数据、执行相应的操作等。公式中表示为$T_{RS}=\frac{L_{RS}}{R_{ACK}}$，其中$L_{RS}$是接收段的长度，$R_{ACK}$是确认应答传输速率。

4. $RTT$中的中断时间 ($\Delta RT{T}_{Disrupt}$)：
   这个是考虑到在往返时延过程中可能发生的中断时间，例如网络拥塞、丢包等引起的中断。

综上所述，公式中的每一项都代表了数据传输过程中的一个重要因素，通过这些因素的考虑，可以更准确地估计数据传输的总时延。

All the terms in (2) are defined in Table I.

The baseline RTT0 in (1) can be formulated as

$$RT{T}_0=T_{Block}+2T_{OWLT}+T_{RS}$$

---

RTO 是 TCP 协议中的一个重要概念，代表重传超时（Retransmission TimeOut）。在 TCP 协议中，当发送方发送数据包后，会等待接收方的确认应答（ACK），如果在一定的时间内未收到确认应答，就会认为数据包丢失了，此时就会触发 RTO，即重传超时机制，发送方会重新发送相同的数据包。

RTO 的值是根据网络状况动态调整的，通常受到往返时延（RTT）、网络拥塞等因素的影响。当网络延迟较高或者出现拥塞时，RTO 的值会增加，以减少误判丢包情况，提高传输的可靠性。反之，当网络状况良好时，RTO 的值会减小，以提高数据传输的效率。

总的来说，RTO 在 TCP 协议中起到了重要的作用，帮助发送方适应不同的网络环境，保证数据的可靠传输。

---

在 LTP（Licklider Transmission Protocol）协议中，checkpoint 是指在数据传输过程中的一个重要标记点。它用于记录发送方成功发送的数据，并且等待接收方对这些数据的确认。

在 LTP 协议中，数据传输可能会遇到各种不可靠的网络环境，比如高延迟、丢包等。为了确保数据的可靠传输，LTP 使用了类似于滑动窗口协议的机制，将数据划分为若干个块，并且在传输过程中不断地发送这些块，同时等待接收方的确认。

checkpoint 在这个过程中起到了关键作用，它标志着发送方成功发送了一段数据，并且等待接收方的确认。如果在发送方收到接收方对该 checkpoint 的确认之前发生了数据丢失或者超时，发送方会重新发送从该 checkpoint 开始的数据块，以保证数据的完整性和可靠性。

因此，checkpoint 在 LTP 协议中类似于一个标记点，用于指示发送方在数据传输中的进度，并且在需要时能够进行数据的重传，从而确保数据的可靠传输。

---

滑动窗口协议：

滑动窗口协议是一种用于在不可靠网络上进行数据传输的协议，它在网络通信中起到了重要的作用，特别是在TCP/IP协议栈中。

滑动窗口协议基于两个主要概念：发送窗口和接收窗口。发送窗口是指发送方在任意时刻可以发送的数据量的大小，而接收窗口则是接收方在任意时刻可以接收的数据量的大小。这两个窗口的大小可以动态地调整，以适应网络的变化。

滑动窗口协议的工作原理如下：

1. 发送方维护一个发送窗口，它指示了发送方当前可以发送的数据段范围。
2. 接收方维护一个接收窗口，它指示了接收方当前可以接收的数据段范围。
3. 发送方发送数据段，并等待接收方的确认应答。
4. 接收方接收数据段，并发送确认应答。
5. 一旦发送方收到确认应答，就将发送窗口向前滑动，允许发送更多的数据段。
6. 如果发送方在一定时间内未收到确认应答，就会重新发送发送窗口中的数据段。

通过这种方式，滑动窗口协议可以实现流量控制和拥塞控制，从而提高数据传输的效率和可靠性。同时，它也能够适应不同的网络条件，动态调整窗口大小，以提供最佳的性能。