基于多流的重传策略论文

　　摘 要 在本篇论文中，针对现有RTP/UDP在传输流媒体的不足，我提出了一种新的传输技术：MSSR-RTP（Multiple Stream Selective Retransmission-Realtime Transmission Protocol，多流选择性重传实时传输协议）应用层协议，然后利用这个协议建立了在Internet中传输H.264/AVC架构体系。在实际项目中成功应用，并显示出其很好的网络特性以及TCP友好特性。
　　关键词 RTP/RTCP；多流；选择性重传
　　现有的Internet网的＂尽力传输模式＂并不能很好的满足Qos的需求，大家都在不断寻求解决方案，著名的Diffserv体系和Intserv体系都是在IP网络中研究Qos提出的，但由于与现有网络的兼容性以及两者体系架构的复杂性，其到目前都没能应用到实际Internet网络中，在对网络有特殊Qos需求的流媒体领域，如何在现有网络体系中最大限度的解决延时，延迟抖动，丢包等问题一直是大家研究的热点。目前的主流解决方案中：RTP/UDP架构在一定程度上解决问题，但其存在不足，针对它的不足，我提出了MSSR-RTP应用层协议，利用这个协议建立了MSSR-RTP/UDP的架构体系。
　　1 介绍
　　在Internet上的流媒体应用越来越广泛，但现有的传输层UDP和TCP协议都不能很好的支持流媒体的传输，其主要原因跟压缩技术和现有的网络体系架构有关。目前在流媒体领域的主流解决方案是：RTP/UDP[1]，即在UDP层上封装RTP层，通过应用层来加强和改善多媒体数据在Internet传输上的性能。但目前这个方案仍有不足，我们以目前的主流视频压缩算法：H.264/AVC[2]为例：
　　a．RTP没有分优先权的字段。
　　H.264/AVC有3种类型的帧（依据不同的软件，其提供的帧类型可能更多）：I帧，进行帧内独立编码，可以看作参考帧；P帧，为前向预测帧，参考前面的I帧和P帧进行编码，采用运动补偿预测帧间误差；B帧编码依赖于前面的和后面的I或P帧。在传输中I帧和P帧数据出现错误，接收端视频流回显质量会受到严重影响。特别是I帧数据，通过实际项目的测试发现，I帧的丢失将使画面出现花屏，并且出现动画效果，画面不够流畅。同时，由于网络资源限制，我们又不能把所有视频数据同样对待，必须对其分类，使得关键数据能得到最大限度保障，而一些不重要的数据就不需要进行重传以减轻网络负担，但RTP机制并没提供对信息分类的功能。在我提出的模型中，利用多流的特点，为每个流设置重传时间，在重传时间内的数据进行重传，超过重传时间的数据进行丢弃，通过这种方法达到对不同优先权的数据进行分类处理。
　　b．RTP无法满足分片的需要。
　　由于视频数据帧通常很大，如果不进行分片的话，分片和重组将给路由器和目的主机增加了额外的负担。花费额外的精力去创建数据报分片和分片重组。由于这个原因，需要将分片保持为最小，这里通过将应用层的数据段限制在一个较小的范围内实现。由于所有IP支持的数据链路协议的MTU都被认为至少有576字节，所以可以使用548字节的MSS、8字节的UDP数据段头部和20字节的IP数据报报头的分片方法。
　　c．无法通过RTP/RTCP来提供拥塞控制和流量管理。
　　网络资源的公平共享提出了要终端提供拥塞控制以防止网络恶化。为了防止接收端被数据＂淹没＂，也需要发送端提供流量管理的功能，但标准RTP机制没有提供这种功能。
　　针对现有架构的不足，提出一种在RTP基础上进行扩展的体系：MSSR-RTP/UDP。利用在终端增加多流技术，分片/重组功能，增加CWND/RWND变量对现有的不足进行改进。
　　2 体系架构
　　根据H.264/AVC和现有Internet的特点，我扩展了RTP/RTCP的功能，提出了MSSR-RTP（Multiple stream selective retransmission-Realtime transmission protocol）模型，其图如图1。
　　系统的研究对象是H.264/AVC，它为网络开发者提供的是I，P，B帧，我把每一帧作为一个发送对象，取名：ADU（Application Data Unit应用程序数据单元）。由于通常视频数据都很大，需要进行分片。分片后通过控制模块添加MSSR-RTP头信息，并把封装后的数据放入缓存，在发送方，无论数据属于哪个流，都放入同一个缓存中。最后由调度中心将数据调入传输层，然后发送到接收方，接收方通过重组分片，收集丢失数据，依据流的特性，将需要重传的数据通过MSSR-RTCP回馈到发送方，进行数据重传。如果一帧的每个分片都到达接收端，则重组为一帧数据上传给解码器。
　　2.1 MSSR-RTP，MSSR-RTCP的头格式以及流结构
　　图2是MSSR-RTP的头格式，作为对标准RTP的扩充，有其新特点。头部信息中，顺序号是用于分片重组的。流序号表示分片是属于哪个流的。流顺序号表示在一个流中的顺序号，如果一个大的ADU分片，那不同片拥有相同的流顺序号。ADU长度是表示此分片对应的ADU的长度。ADU偏移量是表示此分片在对应的ADU中的偏移量。
　　图3是MSSR-RTCP的头格式。MSSR-RTCP是在流媒体传输中与MSSR-RTP协同工作的协议。MSSR-RTCP定期发送供控制模块使用的发送端或则接收端的统计报告。包括发送分组数、丢失分组数、间隔到达的抖动等。对于每个正在发送的RTP分组，发送方会创建并传送RTCP发送方报告分组，在本体系中，与标准的RTCP一致。对于每个正在接收RTP分组的接收方，作为对标准RTCP的扩展，MSSR-RTCP还提供了RWND字段和ACK GAP字段，前者用于在发送端进行流量控制，后者用于进行重传。省略部分与标准RTCP一致，参考文献[1]。
　　图4是流数据结构。作为我提出的结构的核心，它是决定属于此流的数据的重传时间，对于流媒体，它并不需要所有的数据都到达，对于某些延迟超过设定的时间的帧并不需要重传，这是由流媒体自身特点决定，并且，比其传统单流，可以避免头阻塞。
　　2.2 数据传输以及重传策略
　　ADU传到MSSR-RTP层，会首先进行分片处理，然后由控制模块加上MSSR-RTP报头，由调度策略进行数据发送，发送的数据依据其所在流的重传时间决定发送后是否放入缓存。如果重传时间不为0，发送后将缓存，如果重传时间为0，则发送后就丢弃。缓存的数据依据MSSR-RTCP回馈进行重传和移除。其数据传输示意图如下：
　　图5 数据传输
　　服务器端通过函数SR_CREATE创建端口，然后调用函数SR_LISTEN进行侦听，客户端一旦需要接收数据，通过调用函数SR_CONNECT与服务器端建立连接，连接建立后将使用两个端口，一个端口用于传输带有MSSR-RTP头的视频数据，另一个用于传输MSSR-RTCP控制信息。
　　数据发送规则如下：
　　a. 如果发送出去未被确认的数据已经达到或者超过CWND的时候，数据发送者不能再传送任何数据到网络中。
　　b. 当RWND为0的时候，数据发送者不能再传送任何数据到网络中。当未被确认的数据未超过CWND的时候，数据发送者必须保证有一个包在网络中未被确认。
　　c. 当选择发送数据的时候，重发的数据要比新数据优先。
　　通过以上的数据发送规则，能够进行拥塞控制与流量控制，满足对网络资源公平共享的原则，同时也能防止大量视频数据＂淹没＂接收端。
　　重传规则如下：
　　a. 超时重传。
　　b. 接收端通过MSSR-RTCP回馈指示重传。
　　超时重传的原理与TCP中采用的方法一样，RTT的时间计算采用Karn’S算法，参考文献[3]。
　　3 接收端丢失判断和重传策略
　　依据H.264/AVC的网络特点，我们只对I帧数据进行数据重传，并且依据实际项目对实时性的不同要求设置流中重传时间大小。
　　使用MSSR-RTP，接收端通过到达包的MSSR-RTP头部信息来判断包的丢失。通过顺序号，如果没发生数据丢失，则顺序号必定是连续的。如果不连续，则说明发生丢失。对于需要重传的流中，由于需要时间信息来决定是否需要重传，因此必须要知道丢失的＂分片的时间信息，由于I帧数据量大，通常化分成几十上百个片，所以可以通过发现在同一个I帧中其他分片（它们拥有相同的流顺序号）来找出丢失分片的时间信息。
　　a. 一个帧中的分片的丢失判断：通过在流中重组ADU的时候来检测，如果发现顺序号不连续，则说明有分片丢失。这时候的重传策略由这个帧所在的流决定。时间信息通过缺失此顺序号但有相同流顺序号的那些分片提供。
　　b. 一个帧中的开始分片的丢失判断：通过在流中重组ADU的时候来检测。这时通过重组ADU发现找不到偏移量为0的分片知道有开始分片丢失。这时候的重传策略由这个帧所在的流决定。时间信息通过缺失此顺序号的但有相同流顺序号那些分片提供。
　　c. 一个帧中的结尾分片的丢失判断：在重组ADU时，通过发现ADU长度和重组后长度不相等，但顺序号是连续的，则说明一个帧中的结尾分片的丢失，时间信息通过在同一个ADU的其它分片（即：有相同流顺序号的那些分片）提供。这时候的重传策略由这个帧所在的流决定。
　　d. 一个帧中的所有分片丢失判断：在重组ADU时，通过发现不连续的流顺序号说明有一个帧中的所有分片丢失。这种情况，我们将不重传此帧的任何数据。原因是因为I帧数据量大，分片多，全部丢失可能性很小和重传整个I帧代价昂贵。
　　4 结论语
　　此体系架构已经应用在为重庆某集团开发的＂重大危险源实时视频监控系统＂中，通过实际测试，发现其有很好的网络适应性以及TCP友好特性，并且性能比其传统的RTP/UDP有比较多的改善。
　　参考文献
　　[1] Henning Schulzrinne’s RTP site,
　　http://www.cs.columbia.edu/~hgs/rtp/,1999
　　[2] M.-T. Sun and A. R. Reibman, Compressed Video Over Networks.Marcel Dekker Inc., 2001
　　[3] Karn,P., and C.Partridge.1987.Improving round-trip time estimates in reliable transport protocols. Presentation. SIGCOMM’87