基于多流的重传策略论文

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