基于纠删编码的LTP协议优化设计方法.pdf

本发明提出了一种引入纠删编码的LTP协议优化设计方法，将长纠删码与相对于CFDP、BP协议更低层的LTP协议结合，使得纠删码能更直接面对信道，以发挥其差错控制能力，同时对LTP协议的优化能在更小的时间尺度上提供更灵活的方式提升系统的数据传输效率。本发明的方案使得优化后的LTP协议使用H-ARQ机制保障数据的可靠传输，对于绿块数据的传输过程与原LTP协议并无差异，不同之处主要在于红块数据的传输过程。通过仿真实验结果可知，本发明能起到减少优化后LTP协议在深空信道上总传输延时的作用并且可以根据不同的信道条件，合理地调整数据包载荷大小，以取得最优的传输延时与数据传送数量。

1.  一种基于纠删编码的LTP协议优化设计方法，使用所述方法能够缩短LTP协议在深空信道上保障数据可靠传输时的总传输延时，所述方法适用于单程链路延时大于10秒的情况，其特征在于，所述方法的不同之处主要在于红块数据的传输过程，而绿块数据的传输过程与优化前的LTP协议并无差异，所述方法的具体操作步骤如下：
步骤1：收发两端选定具有相同的系统码形式的LDPC码，作为面向数据包的长纠删码使用，约定每一码字的最高有效位MSB方向为原始数据包，最低有效位LSB方向为编码产生的冗余数据包；
步骤2：发送端LTP协议首先根据Block大小及信道条件，选择特定的Segment载荷数据包尺寸；随后发送端将Block划分成数据包并送入编码器进行编码，得到编码后的冗余数据包，按照所述步骤1中约定的原始数据包与冗余数据包顺序送入信道；
步骤3：在信道传输过程中会丢失部分数据包，接收端收到经信道部分删除的数据包后，首先将剩余数据包送入译码器，通过译码操作恢复若干被信道删除的数据包，随后再启动H-ARQ过程重传译码后仍未被恢复的数据包。

2.  根据权利要求1所述的LTP协议优化设计方法，其特征在于：所述步骤1还包括对LTP协议作如下改动：根据所用LEC码长定义一个Session窗口所发送的Segment数量；在每个Segment包头中附加关于编码的额外信息，其中最关键的是告知接收端每个Segment在译码器中的位置，这一位置信息通过包编号表达；因为接收端在反馈前增加了译码过程，发送端的CP定时器应考虑接收端的译码延时，以免产生无谓的虚警。

3.  根据权利要求1所述的LTP协议优化设计方法，其特征在于：在原LTP协议Segment的扩展字段数据中添加与LEC相关的信息。

4.  根据权利要求1所述的LTP协议优化设计方法，其特征在于：所述H-ARQ过程所用编码为编译码复杂度较低的LDPC码。

5.  根据权利要求1所述的LTP协议优化设计方法，其特征在于：所述H-ARQ过程的反馈方式包括：接收端反馈请求发送端重传一切译码恢复失败的数据包；或者，接收端仅反馈请求重传译码恢复失败的原始数据包。

6.  根据权利要求1所述的LTP协议优化设计方法，其特征在于：所述Segment载荷尺寸应适应以太网1500 Byte大小的MTU限制，避免一个Segment被装载到多个以太网MTU内的情况，以提高网络带宽利用率。

基于纠删编码的LTP协议优化设计方法
技术领域
本发明涉及数据传输领域，特别涉及深空信道上的数据传输协议优化设计方法。
背景技术
深空探测能帮助人类更好地认识并探索自己所处的宇宙空间，对人类发展具有深远的意义。深空通信为深空探测任务服务，肩负着航天器与地面站之间数据交互的重任，是深空探测任务成败的关键因素。而深空通信由于环境特殊，具有许多不同于地面通信的特点，如：距离遥远、链路延时大，链路中断频发，误码率较高，上下行速率不对称，以及航天器各方面性能受限等。
深空信道的这些特点给工作在其上的深空通信系统带来了巨大的挑战，就通信协议而言，地面通信中所用的数据传输协议由于假设的工作场景不同，因此往往不可直接应用于深空通信，目前在深空通信中广泛使用的是CCSDS协议体系与DTN协议族，其中DTN协议族可视作CCSDS协议体系在深空通信系统中继化与网络化发展趋势下的补充。
LTP(Licklider Transmission Protocol，Licklider传输协议)是DTN协议族建议的汇聚层协议之一，同时负责实现传输层功能，可实现深空信道上数据的点对点可靠传输。但是LTP协议在深空信道上保障数据可靠传输存在总传输延时过长的问题，其根本原因在于深空信道的高误码率导致LTP协议需要较多的重传次数以保障数据完整性，而深空信道的长延时又导致多次重传的延时巨大。
在深空通信中使用编码的做法由来已久，现阶段在深空通信中得到广泛使用的是纠错码，近年来国内外有关学者尝试将面向数据包的长纠删码与CCSDS协议体系的CFDP协议、DTN协议族的BP协议相结合，有效提高了文件传输效率。
发明内容
基于上述分析，本发明考虑将长纠删码与相对于CFDP、BP协议更低层的LTP协议结合，使得纠删码能更直接面对信道，以发挥其差错控制能 力，同时对LTP协议的优化能在更小的时间尺度上提供更灵活的方式提升系统的数据传输效率。
本发明采取了以下技术方案：
一种基于纠删编码的LTP协议优化设计方法，使用所述方法能够缩短LTP协议在深空信道上保障数据可靠传输时的总传输延时，所述方法适用于单程链路延时大于10秒的情况，且在信道误码率大于10^-6时效果更为显著；所述方法的不同之处主要在于红块数据的传输过程，而绿块数据的传输过程与优化前的LTP协议并无差异，所述方法的具体操作步骤如下：
步骤1：收发两端选定具有相同的系统码形式的LDPC码，作为面向数据包的长纠删码使用，约定每一码字的MSB(Most Significant Bit，最高有效位)方向为原始数据包，最次要位LSB(Least Significant Bit，最低有效位)方向为编码产生的冗余数据包；
步骤2：发送端LTP协议首先根据Block大小及信道条件，选择特定的Segment载荷数据包尺寸；随后发送端将Block划分成数据包并送入编码器进行编码，得到编码后的冗余数据包，按照所述步骤1中约定的原始数据包与冗余数据包顺序送入信道；
步骤3：在信道传输过程中会丢失部分数据包，接收端收到经信道部分删除的数据包后，首先将剩余数据包送入译码器，通过译码操作恢复若干被信道删除的数据包，随后再启动H-ARQ过程重传译码后仍未被恢复的数据包。
作为本发明的进一步改进，所述步骤1还包括对LTP协议作如下改动：根据所用LEC码长定义一个Session窗口所发送的Segment数量；在每个Segment包头中附加关于编码的额外信息，其中最关键的是告知接收端每个Segment在译码器中的位置，这一位置信息通过包编号表达；因为接收端在反馈前增加了译码过程，发送端的CP定时器应考虑接收端的译码延时，以免产生无谓的虚警。
作为本发明的进一步改进，在原LTP协议Segment的扩展字段数据中添加与LEC相关的信息。
作为本发明的进一步改进，所述H-ARQ过程所用编码为编译码复杂度较低的LDPC码。
作为本发明的进一步改进，所述H-ARQ过程的反馈方式包括：接收端反馈请求发送端重传一切译码恢复失败的数据包；或者，接收端仅反馈请求重传译码恢复失败的原始数据包。
作为本发明的进一步改进，所述Segment载荷尺寸应适应以太网1500Byte大小的MTU限制，避免一个Segment被装载到多个以太网MTU内的情况，以提高网络带宽利用率。
本发明的有益效果是：本发明提出的引入纠删编码的LTP协议优化设计方法，将长纠删码与相对于CFDP、BP协议更低层的LTP协议结合，使得纠删码能更直接面对信道，以发挥其差错控制能力，同时对LTP协议的优化能在更小的时间尺度上提供更灵活的方式提升系统的数据传输效率。本发明的方案使得优化后的LTP协议使用H-ARQ机制保障数据的可靠传输，对于绿块数据的传输过程与原LTP协议并无差异，不同之处主要在于红块数据的传输过程。通过仿真实验结果可知，本发明能起到减少优化后LTP协议在深空信道上总传输延时的作用并且可以根据不同的信道条件，合理地调整数据包载荷大小，以取得最优的传输延时与数据传送数量。
附图说明
图1是LTP协议优化设计方案示意图；
图2是本发明所选用LDPC码的译码恢复概率曲线图；
图3是本发明的H-LTP协议DS包结构图；
图4是本发明的H-LTP协议RS包结构图；
图5是本发明的最优传输模式示意图；
图6是本发明的软件实现框图。
具体实施方式
下面结合附图说明及具体实施方式对本发明进一步说明。
本发明将原LTP协议中的ARQ差错控制机制替换为H-ARQ机制，优化后的协议与原LTP协议相比，不同之处主要在于红块数据的传输过程，而绿块数据的传输过程并无差异。因使用了H-ARQ机制，本发明将优化后的协议称为H-LTP协议。
如附图1所示，H-LTP协议的工作流程如下：首先，H-LTP协议通过接口读入高层协议数据单元，并按照当前网络的配置将其划分成Block，再将Block划分成作为Segment载荷的数据包。对于应用程序要求使用不可靠方式传输的绿块数据包，H-LTP将其封装成Segment后即在下一个通信窗口到来时按与LTP相同的方式送入信道，对于要求可靠传输的红块数据包，H-LTP首先将其送入编码器，按照预定的码率得到编码后的一批数 据包。本发明所使用的LEC(Long Erase Code，长纠删码)具有系统码形式，所以编码后的数据包可清晰地区分原始数据包和编码冗余数据包。随后H-LTP给编码后的数据包加上包头，封装为红块DS，即可在下一个通信窗口送入信道。
接收端收到发送的红块DS后，因信道的删除作用，会有部分DS丢失。对于未丢失的DS，接收端会根据包头中所标注的信息，将收到DS的载荷部分取出得到数据包，并将数据包送入译码器进行迭代译码。译码的目标是保证所有的原始数据包都可在译码器的输出端恢复，此时当前Session该批次的原始数据发送即告成功，接收端向发送端反馈ACK而无需进行数据重传过程。随后接收端会将收到的数据包重新拼接成Block，再将各Block拼接成高层协议数据单元递交予高层。
如接收端未能通过译码恢复所有的原始数据块，接收端会启动ARQ过程，向发送端反馈丢失的数据块对应包编号，发送端会重新发送接收端所请求的数据包，并开始新一轮的译码判断过程，直至所有原始数据传输成功为止。值得注意的是，收发两端的反馈过程可按接收端反馈内容的不同而分成以下两种方式。
第一种方式是接收端反馈请求发送端重传一切译码恢复失败的数据包，虽然重发丢失的冗余数据包会占用一定的带宽，但是接收端得到更多的冗余数据包后能加快译码恢复全部原始数据包的速度，本发明将这种反馈方式记为H-LTP反馈方式一，简称为H-LTP方式一。
第二种方式是接收端仅反馈请求重传译码恢复失败的原始数据包。值得注意的是，接收端上一轮译码结束后，译码器输出端的冗余包所含有的信息已经不能恢复更多的原始数据包了。这种反馈方式下虽然反馈重传后接收端不能通过重传获得新的冗余包——也就是新的冗余信息——但在后续译码过程中可通过新得到的原始数据包恢复出额外的冗余信息，这些冗余信息又可投入到新的迭代过程中去，因此在该反馈方式下虽然未重传冗余数据包但仍可保证冗余数据包在迭代译码中的有效性，且可节约发送端发射带宽，是一种兼顾收发两端性能方案。本发明将此反馈方式简称为H-LTP方式二。
为了完成H-LTP有关功能，需要对协议做如下改动。首先需要根据所用LEC长定义一个Session窗口所发送的Segment数量；其次需要在每个Segment包头中附加关于编码的额外信息，其中最关键的是告知接收端每个Segment在译码器中的位置，这一位置信息通过包编号表达；最后，因 为接收端在反馈前增加了译码过程，发送端的CP(CheckPoint，检查点)定时器应考虑接收端的译码延时，以免产生无谓的虚警。
适用于优化LTP协议的长纠删码应具有较高的译码恢复概率、适中的码率，同时考虑航天器搭载设备的性能，还应具备较低的编译码复杂度(等价于较短的编译码时延)，否则将不能保证重新设计的LTP协议传输延时更短。本发明所选用LDPC码在不同迭代次数下的译码恢复概率如附图2所示。
H-LTP协议的数据包头中应包含与LEC相关的信息，遵循与原LTP协议尽量兼容的设计思想，最佳设计结果应该是在不改变原协议数据包布局与功能的前提下完成LEC编码信息的添加。在接收端，包含LEC编码信息的数据包应能够被原LTP协议相关功能函数正确识别，并分离出有效载荷交由译码器处理。只有满足这些要求才可实现实际工作中协议在ARQ机制和H-ARQ机制间无缝切换，增加本发明的实用性与灵活性。使用原LTP协议Segment的扩展字段可良好实现上述构想。相对于原LTP协议，H-LTP协议也有4种类型的Segment，其中RA(Report-Acknowledge Segment，报告确认段)和SS(Session management Segment，会话管理段)与原LTP协议相同，DS(Data Segment，数据段)和RS(Reprot Segment，报告段)与原协议不同。
考虑下层网络效率因素，因H-LTP Segment可能在以太网上传送，实际应用中建议Segment载荷尺寸应适应以太网1500Byte大小的MTU限制，避免一个Segment被装载到多个以太网MTU内的情况，以提高网络带宽利用率。
DS包结构如附图3所示。其中包头部分各种类型的Segment都相同，总计48bit的包头信息。首先是4bit协议版本号，原LTP这四位是0000，H-LTP为了与原LTP兼容同样设为0000。随后是4bit控制位，Segment的类型通过4位控制位加以区分，H-LTP对控制位的定义与原LTP相同，当4bit控制位为00xx时(x表示随意)，为红块，而为0100/0111时，为绿块。不同的xx自然对应不同功能的红块，此处暂不赘述。16bit的会话发起引擎号和会话编号用于对session加以区分，类似ip地址和端口号。值得注意的是，包头中两个16bit的SDNV变量，实际应用时可能并没有16bit那么长，这取决于系统中能并发多少个Session。对于8bit SDNV，数据包格式层面最多可支持127个Session，为了增加设计余量，避免出现类似Internet问世多年后IPV4地址不足的问题，本发明的方案采用16bit SDNV，数据包层面最多可区分＝16384个Session，这对于深空任务是绰绰有余了。包头的最后是两个4bit的计数变量，用于说明包头和包尾各有多少个扩展字段，包头和包尾的扩展均以TLV数据类型存储。
本发明将LEC编码信息以TLV形式存放在包头扩展中，且定义当Tag值为0x02时，当前TLV存储的是当前DS运载的编码后数据包编号，以便将数据包输入至译码器正确的节点。对于本发明的方案所选系统码形式的LEC，当编码后数据包编号大于1023时(从0开始编号)，则说明当前DS运载的是冗余数据包，随后载荷目录域中的偏置位置字段将不予计算。
包头扩展域之后是载荷目录，载荷目录可以理解为载荷的元数据，负责告知协议如何处理当前载荷。8bit客户端服务编号用于区分需要该载荷的上层协议接口，由于多个会话的数据可以汇入同一上层协议接口，所以127个接口已足够使用。偏置位置用于表示当前DS载荷的第一字节在原Block中的位置，考虑到可能的Block大小，取32bit SDNV值，最大可支持228Byte＝256MB的Block，可满足本发明的方案所假设的待传送文件大小需求。16bit SDNV载荷长度最大可支持Byte＝16MB的文件，这对于一个Segment来说看起来有点过大，但考虑若仅用8bit SDNV表示载荷大小，最大只能支持127Byte的载荷，这又显得过小，因此只好取16bit SDNV。
原版LTP规定传输过程中每个RS和CP都有唯一的随机编号且不可为0，随机编号的原因是为了防止DoS攻击，且工作中一个RS对应一个CP，二者具有相同的CP编号，表示该RS是对拥有同样检查点编号CP的响应。出于设计余量考虑，将二者都设为16bit SDNV。本发明的方案中对于非CP且首轮发送的数据包，将此二SDNV变量设为0。
在载荷目录之后就是当前Segment携带的载荷，接收端将其提取后，即可按照包头扩展域中携带的LEC编码信息将其送入译码器的指定节点进行译码。
H-LTP协议的RS包结构如附图4所示。RS包头部分与DS完全相同，都为48bit开销。
RS载荷目录第一个变量是一个16bit SDNV的RS编号。之后是16bit SDNV的CP编号，接收端每个RS的产生都是因为收到了发送端发来的一个CP，所以反馈至发送端的RS需说明是回应了哪一个CP。之后是各32bit的缺失数据的上界和下界，上界和下界的具体数值表示缺失数据在原Block中的偏置字节数。原LTP协议设计上界与下界是为了帮助各RS划 定自己的反馈范围，且上界不应小于下界。而H-LTP中反馈的是编码后数据包编号，因此可人为将上界各bit位置0，将下界各bit位置1，发送端检测到这一人为差错后会跳过对上界与下界的处理，实现对本发明的方案RS和原LTP协议RS的区分。之后是8bit SDNV的重传请求数量，RS的载荷是一条一条的重传请求(Reception Claim，简称RC)，该变量说明了当前RS中RC的数目，由于每条RC的长度固定，因此该变量的数值也就间接说明了当前RS的长度。和DS不同，RS属于信令Segment，其需要有比DS低得多的丢包率以保障协议的高效运转。为了达到这一要求，除了降低反向信道发射速率以提高每比特能量进而降低反向信道误码率外，另一个途径就是限制RS的包长不得超过某一上限，本发明的方案中限定一个RS中最多有127个RC，以限定其总长度不超过4152bit。
载荷中的RC格式本发明的方案规定如下，每个RC长32bit，前16bit SDNV表示当前RC覆盖的第一个有错数据包编号，后16bit SDNV表示当前RC覆盖的最后一个数据包编号相对于第一个的偏移量，如果认为多条RC逐步向前推进以求覆盖全部错误的数据包，那么该偏移量就是RC的“步长”。
考虑2048个数据包每间隔一个错一个的情况，无疑此时需要的RC数量最多，共需1024个RC，实际工作中出现这种极端情况是比较罕见的，但是一旦总共需要的RC数量多于一个RS能携带的RC数量上限，就需要组织多个RS进行反馈，和原版LTP协议的规定一样，这多个RS都对应同样一个CP编号。
H-LTP和LTP一样，在发送数据包时会将最后一个数据包标记为CP，接收端收到标记为CP的数据包，即得知发送端已将全部数据包发送完毕，随即启动译码过程，译码结束后，选择反馈方式一至三中的一种进行反馈重传。CP触发型反馈的关键点在于CP必须能够成功传到接收端，否则接收端就不能启动译码过程，为保证CP的可靠传输，可在发送端设置一定时器来检测CP的传输状态，具体的定时器值T_CP计算方法如下：
T_CP＝2×OWLT+T_TX-txmt+T_TX-process+T_RX-recv+T_RX-process+T_RX-DMAX
其中各变量含义如下，OWLT表示单程链路延时；T_TX-txmt表示发送端发射延时；T_TX-process表示发送端处理延时，指发送端为了完成相关内部操作所做需的时间；T_RX-recv表示接收端的接收延时，加入此变量是为了考虑接收机排队的情况，实际应用中因接收机排队情况罕见，该值大多数时候可以忽略；T_RX-process表示接收端处理延时，指接收端为了完成相关内部操作所需的 时间；T_RX-DMAX表示接收端最大译码延时，即迭代次数达到上限是的译码延时。实际应用中，T_CP的取值主要由T_TX-txmt、T_RX-DMAX、2×OWLT决定。
按照上述数值设计CP定时器后，可在发射CP的同时启动定时器，若定时器耗尽之前接收端的RS成功传到，则可以按RS反馈的内容进行随后操作；若计时器耗尽后RS还没有传到，说明CP或者RS发生了丢包，此时只需重发CP并再次启动CP定时器即可。
与CP定时器的延时构成相似，接收端RS定时器的计时值可表达为：
T_RS＝2×OWLT+T_RX-txmt+T_RX-process+T_TX-recv+T_TX-process
其中T_RX-txmt为接收端发射延时，T_TX-recv为发送端接收排队延时。
发送端RA的定时器与接收端RS定时器有着相同的结构，此处不再赘述。
在相同的信道误码率BER和较大的单程链路延时OWLT条件下，决定H-LTP与LTP延时性能孰优孰劣的关键在于H-LTP所用纠删码的码率、译码恢复概率以及Session窗口容量和形状的选择上。在码率相同的情况下，选用译码恢复概率越高的长纠删码，优化后协议的延时性能越优。在考虑链路中断的情况下，如优化得当，H-LTP所需总链路连通时间的缩短可使得所有数据包的传输过程经历更少次数的链路中断，在总传输延时性能上能够获得额外的提升。
考虑LTP下层的数据链路层，如数据链路层对上层透明传输，则H-LTP协议性能会受到CP丢失概率的限制，如数据链路层可识别出上层协议的信令包并加以额外保护，则可进一步提升H-LTP协议性能，如附图5所示。
本发明可有效解决原LTP协议在深空信道上保障数据可靠传输延时较长的问题，通过合理的设计，本发明可以实现在H-LTP于原LTP协议间的灵活切换，并且根据具体信道情况选择最优传输模式。
使用H-ARQ机制作为LTP协议的差错控制机制时，总传输延时是否缩短，在信道误码率较低时取决于所选长纠删码的译码恢复概率、码率、以及协议所传输数据包的长度不同的组合情况可能导致不同的延时变化情况；而在信道误码率较高时仅取决于长纠删码的译码恢复概率与码率。
H-LTP的两种工作方式在本发明的方案给出的协议配置参数和信道条件下，都能极大地缩短总传输延时，相比原LTP协议在同等条件下相比，当信道误码率较低时，H-LTP协议传输延时约为原LTP协议传输延时的80％-90％，当误码率较高时，H-LTP协议传输延时可低至原LTP协议传输延时的20％-40％之间。而比较H-LTP协议的两种工作方式，在信道丢包 率较大时，方式一的总延时略小于方式二，在信道丢包率较小时，二者的总延时无明显差异。因此在信道条件较好时可选用方式二以节约信道带宽。
对于给定的长纠删码，在一定的信道条件下存在使得总延时最小的数据包长度，对于本发明的方案所用LDPC码与给定的信道误码率条件，最优数据包长度均为512字节。
综上所述，使用长纠删码优化传输协议时，可首先根据信道误码率和可能的数据包长度选项确定对应丢包率的取值范围，再根据丢包率选择译码恢复概率和码率能符合性能需求的长纠删码，最后再结合长纠删码反向优化数据包长度，即可得到性能较优的协议优化方案。关于本发明的方案一个可行的软件实现流程如附图6所示。
以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说，在不脱离本发明构思的前提下，还可以做出若干简单推演或替换，都应当视为属于本发明的保护范围。