基于FEC／ARQ的流媒体可靠实时通信

第４８卷第５期　２００２年ｌ０月　武汉大学学报（理学版）　

Ｊ．Ｗｕｈａｎ　Ｕｎｉｖ．（Ｎａｔ．Ｓｃｉ．Ｅｄ．）　Ｖｏ１．４８　ＮＯ．５　

（）ｃｔ．２００２．６２６～６３０　

文章编号：０２５３—９８８８（２００２）０５—０６２６－０５　基于ＦＥＣ／ＡＲＱ的流媒体可靠实时通信　

罗云峰，朱秋萍　，朱　霓　（武汉大学电子信息学院，湖北武汉４３００７２）　

摘　要：在研究可靠组播通信中差错控制技术的基础上，结合流媒体通信的特点尤其是其通信协议．提出了一　个基于ＦＥＣ和ＡＲＱ混合纠错技术的可靠实时流媒体通信模型，对其通信过程进行了详细描述，并初步实现了相　关协议算法，经仿真实验证明该模型在实时性、带宽利用率和拥塞控制等方面都达到了较理想的效果．　关键词：流媒体；实时通信；组播通信；前向纠错编码；自动重传请求　中图分类号：ＴＮ　９ｌ　文献标识码：Ａ　

０　引　言　流媒体是指在Ｉｎｔｅｒｎｅｔ／Ｉｎｔｒａｎｅｔ上使用流式传　输技术的连续时基媒体．流式传输方式将整个　Ａ／Ｖ、３Ｄ等多媒体文件经过特殊的压缩方式分成一　个个压缩包，由流媒体服务器和用户计算机连续、实　时的通信．在采用流式传输方式的多媒体系统中，用　户只需经过几秒或几十秒的启动延时即可在用户的　计算机上利用解压设备（硬件或软件）对压缩的　Ａ／Ｖ、３Ｄ等多媒体文件解压后进行播放和观看，节　省了下载大存储量的多媒体文件的时间．因此，流　媒体技术在Ｉｎｔｅｒｎｅｔ／Ｉｎｔｒａｎｅｔ上如视频会议、远程　教学、视频点播等多媒体系统中得到了广泛的应用．　流媒体技术的应用对网络带宽、传输时延、分组　丢失有着严格的要求．为了满足其实时要求，流媒体　通信采用了不可靠传输协议ＵＤＰ，这是由于可靠传　输协议ＴＣＰ是建立在差错控制技术自动重传请求　ＡＲＱ（Ａｕｔｏｍａｔｉｃ　Ｒｅｐｅａｔ　Ｒｅｑｕｅｓｔ）基础之上的，其　往返而造成的网络时延远不能满足流媒体通信的实　时要求；然而基于ＵＤＰ的流媒体通信质量由于网　络通信中不可避免的分组丢失率而严重降低．虽然　目前高性能的网络技术已经成熟，但是旧的网络设　施的改造还将是一个漫长的过程，网络通信中的分　组丢失率仍然不可避免．于是，在目前的网络设施基　础上改进流媒体的通信技术成为保证流媒体通信质　量的必由之路．　本文提出了一种建立在ＵＤＰ之上的流媒体通　信模型，通过把前向纠错技术ＦＥＣ（Ｆｏｒｗａｒｄ　Ｅｒｒｏｒ　Ｃｏｒｒｅｃｔｉｏｎ）和自动重传请求纠错技术ＡＲＱ结合在　一起，控制流媒体服务器和客户端的数据包的发送　和接收，根据网络运营情况自动调整数据包传输，从　而达到流媒体的可靠实时通信．　１　组播通信中的差错控制技术　目前，组播通信中的差错控制技术的有效方式　为混合ＦＥＣＥ　，其结构框架如图１．　应用层　可靠组播层／前向纠错层　网络层　数据链路层　图ｌ混合ＦＥＣ框架　混合ＦＥＣ把ＦＥＣ和可靠组播层结合起来作为　一独立层，在发送端采用ＲＳ（Ｒｅｅｄ　Ｓｏｌｏｍｏｎ）算法　编码［３］，把每ｋ个原始数据包作为一个数据块通过　变换生成　—ｋ个校验包，然后发送给接收端对应层　ｋ＋ａ（０≤ａ≤　—ｋ）个数据包．在接收端，如果检测　接收到的数据包数量不足ｋ个，则向发送端发送继　

收稿日期：２００２—０４—２６　十通讯联系人Ｅ—ｍａｉｌ：ｑｐｚｈｕ＠ｗｈｕ．ｅｄｕ．ｃｎ　基金项目：国家自然科学基金资助项目（６９９８３００５）　作者简介：罗云峰（１９７７一），男，硕士生，现从事多媒体信息处理与网络通信研究　

维普资讯 http://www.cqvip.com 第５期　罗云峰等：基于ＦＥＣ　ＡＲＱ的流媒体可靠实时通信　续传输请求，然后发送端发送剩余尚未发送的校验　包．若接收端接收到的数据包仍然不足ｋ个，则继续　向发送端提出继续传输请求．若发送端已经发送完　，　个数据包，则重传数据块．　其中采用的ＲＳ编码是一种ＦＥＣ循环码，其主　要思想是把ｋ个原始数据包通过编码变换生成，　—　ｋ个校验数据包，使得ｋ个原始数据包和　—ｋ个校　验数据包共　个数据包中的任何ｋ个数据包子集都　能够恢复出原始数据包，因此允许传输过程最多丢　失　—ｋ个数据包．　参考文献［４，５］对混合ＦＥＣ就延迟、拥塞和带　宽３个方面进行了详细的对比和评测，得出混合　ＦＥＣ能够使组播通信性能在多方面得到提高：（１）　数据可靠传输时间显著减少；（２）满足了实时通信　的时限；（３）降低网络拥塞；（４）相对其它网络协议　包括为实现组播通信但没有采用预传输校验包的组　播协议提高了带宽利用率；（５）能够在不同时空特　性的不同拓扑结构的网络中具有较好的扩展性．　２　流媒体通信中的差错控制技术　２．１通信方式　流媒体通信存在单播和组播两种通信方式．若　采用单播通信方式，需要在发送端发送数据包的多　个拷贝，以多个点对点的方式实现点和多点之间的　通信．在组播通信方式中，允许路由器一次将数据复　制到多个通道上，所有通信用户共享同一个信息包，　从而服务器只需要发送一个信息包，减少了网络上　传输的信息包的总量，避免了单播通信方式中造成　的网络资源的巨大浪费，提高了利用效率．　根据流媒体通信的特点，把组播通信中的混合　ＦＥＣ差错控制技术应用到流媒体通信领域，结合流　媒体通信协议尤其是实时传输控制协议，建立基于　ＦＥＣ／ＡＲＱ纠错技术的流媒体通信模型，必然可以　进一步降低其通信中网络时延和拥塞率，提高网络　带宽利用率，从而达到流媒体的可靠实时通信．　２．２通信过程描述　在流媒体的可靠实时通信过程中，大致可分为　３个阶段：第ｌ阶段为通信建立阶段，即各用户通过　ＴＣＰ向流媒体服务器递交通信申请，并建立通信；　第２阶段为通信阶段，各用户和流媒体服务器之间　进行可靠实时通信，ＲＴＰ（Ｒｅａｌｔｉｍｅ　Ｔｒａｎｓｐｏｒｔ　Ｐｒｏ—　ｔｏｃｏ１）　、ＲＴＣＰ（Ｒｅａｌｔｉｍｅ　Ｔｒａｎｓｐｏｒｔ　Ｃｏｎｔｒｏｌ　Ｐｒｏ—　ｔｏｃｏ１）［引、ＲＴＳＰ（Ｒｅａｌ　Ｔｉｍｅ　Ｓｔｒｅａｍｉｎｇ　Ｐｒｏｔｏｃｏ１）　、　ＲＳＶＰ（Ｒｅｓｏｕｒｃｅ　ＲｅｓｅｒＶａｔｉｏｎ　Ｐｒｏｔｏｃｏ１）ｌ＿８　等通信协　议为通信提供质量保证；第３阶段为通信结束阶段．　在通信过程的描述中，定义Ｓ表示流媒体服务　器，Ｒ　表示第ｉ个客户端．　２．２．１通信建立阶段　（１）Ｒ　通过ＴＣＰ向Ｓ递交通信申请，并提供自　己网络特性参数；　（２）Ｓ接收各用户递交的通信申请，根据所有　用户的网络特性参数，如接收者整体数量　、最大网　络时延ｔ…、平均网络时延ｔ　…最小网络时延ｔ　。　、　缓冲时间ｔ　通信质量要求ｑ　等，调用初始化策略　确定采用ＲＳ编码算法的　、ｋ值并估算初始预发送　数据包数量ｋ＋ｎ（０≤ｎ≤　一是），包括ｋ个原始数据　包和ａ个校验包．如果已经开始通信，参数值则由调　整策略确定；　（３）开始通信．　２．２．２通信阶段　（１）Ｓ发送ｋ＋ｎ个数据包至Ｒ　；　（２）Ｒ　开始接收数据包，每接收一个数据包后　计算当前接收数据块时间限制，通过ＲＴＣＰ报告通　信质量参数．若Ｒｉ在当前接收数据块时间限制前所　接收的数据包数量ｚ＜ｋ，则向Ｓ发送ＲＴＣＰ／ＮＡＫ　数据包，告知当前用户需要接收更多的校验包才能　恢复出满足通信质量要求的原始数据包．　．　为此，定义ＲＴＣＰ新数据包类型ＲＴＣＰ／ＮＡＫ，　其格式如图２．　

０　１　２　３　４　５　６　７　８　９　０　１　２　３　４　５　６　７　８　９　０　ｌ　２　３　４　５　６　７　８　９　０　１　ｌＶ＝２　ｌＰ　ｌ　ｓｃ　ｌ　ＰＴ＝ＮＡＫ＝２０５　ｌ　ｌｅｎｇｔｈ　ｌ　

：十＝＋＝十＝十＝十：＝＋＝＋：＋＝十＝＋＝十＝十＝十＝十：十＝十＝十＝十＝十＝十＝十　ｌ　ＳＳＲＣ／ＣＳＲＣ一１　Ｉ　

ｆ　ｃｏｕｎｔ１　ｆ　＋＝＋＝＋＝十＝十＝十＝＋＝＋＝＋＝＋＝十＝十＝十＝十＝十＝十＝十：十＝十＝十＝十＝十　ｌ　ＳＳＲＣ／ＣＳＲＣ一２　ｌ　

＋一＋一＋一＋一＋一＋一＋一＋一＋一＋一＋一＋———＋一—　一—　一＋一＋一＋一十一＋一＋一　ｌ　ｃｏｕｎｔ一２　Ｉ　

＋＝＋＝＋＝＋＝＋＝＋＝＋＝＋＝＋＝＋＝十＝＋＝十＝十＝十＝十＝十＝十＝十＝十＝十＝十　ｌ　Ｉ　

＋＝＋＝＋＝＋＝＋＝＋＝＋＝＋＝＋＝＋＝｝＝＋＝十＝十＝＋＝十＝十＝十＝十＝十＝十＝十　

图２　ＲＴＣＰ／ＮＡＫ数据包格式　版本（　）：２　ｂｉｔ　填充（Ｐ）：１　ｂｉｔ　数据源数目（Ｓｏｕｒｃｅ　Ｃｏｕｎｔ）：５　ｂｉｔ　数据包类型（Ｐａｃｋｅｔ　Ｔｙｐｅ）：８　ｂｉｔ，ＮＡＫ一２０５　来确认数据包的类型为ＲＴＣＰ／ＮＡＫ．　数据包长度（１ｅｎｇｔｈ）：１６　ｂｉｔ，数据包长度为整　个数据包的长度，包括数据包头和其填充数据长度．　数据源标识（ＳＳＲＣ／ＣＳＲＣ—ｎ）：３２　ｂｉｔ，数据包需　要发送的目的数据源标识　所需额外校验包数量（ｃｏｕｎｔ）：３２　ｂｉｔ　（３）Ｓ根据ＲＴＣＰ／ＮＡＫ数据包信息，凋用调　整策略确定为实现可靠通信所需要校验包数量，调　

维普资讯 http://www.cqvip.com ６２８　武汉大学学报（理学版）　第４８卷　整发送校验包数量，继续发送校验包至各接收者．　（４）重复（２）（３）步骤至稳定通信，即在满足所　有客户端通信质量要求下的可靠流媒体实时通信．　２．２．３　结束阶段　（１）Ｒ　发送ＲＴＣＰ／ＢＹＥ数据包至Ｓ，退出当前　通信．　（２）Ｓ根据ＲＴＣＰ／ＢＹＥ数据包信息调整发送　策略．若所有用户均退出当前通信，则Ｓ结束当前　通信，释放相应资源．　（３）通信结束．　３　流媒体通信实现方案　３．１通信协议算法实现　在流媒体通信过程中，仅存在流媒体服务器和　客户端两种角色．因此，对协议算法可以从这两个不　同角色的角度去实现．　３．１．１　服务器　基于流媒体的通信过程，其服务器端的流程图　如图３，且算法描述为：　Ｌｉｓｔｅｎ（）；／／监听网络　／／如果为连接请求　Ｉｆ（ＩｓＣｏｎｎｅｃｔＲｅｑｕｅｓｔ（））　｛　／／如果尚未开始通信　Ｉｆ（ＩｓｎｏｔＣｏｍｍｕｎｉｃａｔｉｏｎ（））　Ｉｎｉｔｉａｌｉｚｅ（）；　／／调用初始化策略　Ｅｌｓｅ／／用户加入通信　Ａｄｊｕｓｔ（）；　／／调用调整策略　｝　／／否则如果为续传或退出请求　Ｅｌｓｅ　Ｉｆ（ＩｓＲｅｐｅａｔＲｅｑｕｅｓｔ（）ｏｒ　ＩｓＢｙｅＲｅｑｕｅｓｔ　（））　Ａｄｊｕｓｔ（）；　／／调用调整策略　／／进行Ｒｅｅｄ　Ｓｏｌｏｍｎ编码　●　ＲｅｅｄＳｏｌｏｍｎＣｏｄｅ（）；　Ｓｅｎｄ（）；　／／发送　图３服务器端流程图　３．１．２客户端　基于流媒体的通信过程，其客户端的流程图如　图４，且算法描述为：　Ｌｉｓｔｅｎ（）；　／／监听　／／如果为视频数据包　Ｉｆ（ＩｓＭｅｄｉａＰａｃｋｅｔ（））　｛　／／进行Ｒｅｅｄ　Ｓｏｌｏｍｎ解码　ＲｅｅｄＳｏｌｏｍｎＤｅｃｏｄｅ（）；　／／如果不能重构原始数据　Ｉｆ（！ＣａｎＲｅｃｏｎｓｔｒｕｃｔＳｏｕｒｃｅＤａｔａ（））　／／重组续传数据包　ＣｏｎｓｔｒｕｃｔＲｅｐｅａｔＲｅｑｕｅｓｔ（）；　｝　／／否则如果为其它通信用户发送的续传数据包　Ｅｌｓｅ　Ｉｆ（ＩｓＲｅｐｅａｔＲｅｑｕｅｓｔ（））　／／重组续传数据包　ＣｏｎｓｔｒｕｃｔＲｅｐｅａｔＲｅｑｕｅｓｔ（）；　Ｓｅｎｄ（）；　／／发送