CN102845008B - 报文冗余度调整方法、相关设备及网络系统 - Google Patents

Abstract

一种报文冗余度调整方法包括：获取发送端已向接收端发送的报文序列中各丢包事件的发生次数；根据各丢包事件的发生次数，确定待使用的冗余度，其中，待使用的冗余度是能使所述报文序列的丢包率满足丢包要求的冗余度中最小的冗余度；控制发送端利用所述待使用的冗余度向接收端发送报文。一种发送设备，包括：获取单元，用于获取所述发送设备已向接收设备发送的报文序列中各丢包事件的发生次数；冗余度确定单元，用于根据各丢包事件的发生次数，确定待使用的冗余度，其中，待使用的冗余度是能使所述报文序列的丢包率满足丢包要求的冗余度中最小的冗余度；发送单元，用于利用所述待使用的冗余度向所述接收设备发送报文。

Description

报文冗余度调整方法、相关设备及网络系统

技术领域

本发明涉及通信技术领域，特别涉及一种报文冗余度调整方法、相关设备及网络系统。

背景技术

基于网际互联协议(InternetProtocol，简称“IP”)的分组交换网络在近几十年来得到了蓬勃的发展，成为覆盖全球的通信网。IP网络具有低成本等优势，随着通信的发展，包括语音业务在内的传统的电信业务也越来越多地使用IP网络承载，承载实时语音业务的IP网络也称为分组语音(VoiceoverIP，简称“VoIP”)网络。例如，H.323网络、下一代网络(NextGenerationNetwork，简称“NGN”)等都是VoIP网络。

VoIP网络可以承载实时性要求较高的业务，例如实时语音、实时视频、实时数据等业务，一般使用实时传输协议(Real-TimeTransferProtocol，简称“RTP”)作为实时业务的承载协议。RTP是针对IP网络上多媒体数据流的一个传输协议，其被定义为在一对一或一对多的传输情况下工作，其目的是提供时间信息和媒体流同步。RTP的典型应用建立在用户数据报协议(userdatagramprotocol，简称″UDP″)上，但也可以异步传输模式(asynchronoustransfermode，简称″ATM″)等其他协议之上工作。其中，典型的VoIP网络上语音报文格式为：物理链路层+IP协议层+UDP协议层+RTP协议层+语音数据。

RTP本身只保证实时数据的传输，但是由于IP网络是面向无连接的不可靠网络，所以导致RTP包可能会在传输过程中丢失。但是，实时业务又要求网络服务质量(qualityofservice，简称“Qos”)达到一定要求。例如，一般要求为丢包率低于1％、延时低于100毫秒(ms)、网络抖动小于20ms。因此，为了保证实时业务的Qos，需要采用冗余机制恢复传输过程中丢失的数据。

其中，RFC2198定义的冗余机制的基本原理是：每个当前RTP报文携带前一个或者前几个RTP报文的内容，当某个RTP报文丢失时，可以从后续的RTP报文携带的冗余中恢复丢失的RTP报文。例如，在发送时，如果没有冗余包，报文传送序列为RTP1、RTP2、RTP3、RTP4，其中，RTPi表示第i个RTP报文。如果每个RTP报文携带一个冗余包，则报文传送序列为RTP1、RTP2/RTP1、RTP3/RTP2、RTP4/RTP3；如果每个RTP报文携带两个冗余包，则报文传送序列为RTP1、RTP2/RTP1、RTP3/RTP2/RTP1、RTP4/RTP3/RTP2。其中，报文中第一个“/”后的部分称为冗余包，第一个“/”前的部分称为主包。若传输过程中没有丢包，则接收方只把主包作为有效业务包，丢弃冗余包；若传输过程中有丢包，在每个RTP报文携带一个冗余包情况时，若报文RTP2/RTP1丢失，则接收方会从报文RTP3/RTP2中解出主包RTP2，形成完整的报文序列RTP1、RTP2、RTP3....。

其中，RFC2733协议定义的冗余机制的基本原理是：在发送报文序列中增加携带前向纠错(ForwardErrorCorrection，简称“FEC”)信息的冗余报文，接收方可以使用冗余报文恢复丢失的RTP报文。在具体实现时，可以从媒体数据流中抽取若干个RTP报文，并对它们做异或操作，生成一个包含FEC信息的冗余报文，这个冗余报文可以被接收端用来恢复任何一个用来产生它的RTP报文。例如，没有冗余报文时的报文发送序列为a、b、c、d。有冗余报文时的报文发送序列为a、b、f(a，b)、c、d、f(c，d)，其中，f(a，b)是冗余报文，表示报文a和报文b异或的结果。在接收方，如果没有报文丢失，则直接丢弃冗余报文f(a，b)和f(c，d)；如果报文b丢失，则将报文a和报文f(a，b)异或后即可以恢复报文b，从而实现了丢包补偿。如果报文发送序列为a、f(a，b)、b、f(b，c)、c、f(c，d)、d，可以补偿连续两个报文的丢失。在接收方，如果报文b、c丢失，则可以将a和f(a，b)异或恢复b，将b和f(b，c)异或恢复c。

使用RFC2198定义的RTP冗余机制时，现有技术方案一般是在呼叫建立时确定每个RTP报文携带的冗余包个数，后续在呼叫过程中每个报文都携带固定的冗余包个数；使用RFC2733定义的RTP冗余机制时，现有技术方案一般在呼叫建立时确定呼叫使用的冗余纠错方式，并在呼叫过程中一直使用该冗余纠错方式。

现有技术具有如下缺点：

由于现有技术方案中采用了固定的冗余度进行补偿，如果在呼叫过程中网络传输环境恶化，则会导致丢包率上升，无法满足业务的QoS需求。

发明内容

本发明实施例提供一种报文冗余度调整方法、相关设备及网络系统，能够降低业务丢包率，保证业务质量。

有鉴于此，本发明实施例提供：

一种报文冗余度调整方法，包括：

获取发送端已向接收端发送的报文序列中各丢包事件的发生次数；

根据各丢包事件的发生次数，确定待使用的冗余度，其中，待使用的冗余度是能使所述报文序列的丢包率满足丢包要求的冗余度中最小的冗余度；

控制发送端利用所述待使用的冗余度向接收端发送报文。

一种发送设备，包括：

获取单元，用于获取所述发送设备已向接收设备发送的报文序列中各丢包事件的发生次数；

冗余度确定单元，用于根据各丢包事件的发生次数，确定待使用的冗余度，其中，待使用的冗余度是能使所述报文序列的丢包率满足丢包要求的冗余度中最小的冗余度；

发送单元，用于利用所述待使用的冗余度向所述接收设备发送报文。

一种网络系统，其包括：上述发送设备，以及接收设备，

所述接收设备，用于接收所述发送设备发送的所述报文序列和所述报文；向所述发送设备上报所述报文序列中各丢包事件的发生次数。

本发明实施例根据报文序列中各丢包事件的发生次数，确定能使报文序列的丢包率满足丢包要求的冗余度中最小的冗余度为待使用的冗余度，然后控制发送端利用所述待使用的冗余度向接收端发送报文。由于采用该待使用的冗余度补偿后的丢包率满足丢包要求，所以能够保证业务质量；且由于发送端待使用的冗余度是满足丢包要求的冗余度中最小的冗余度，因此，可以使业务传输需要的带宽减小，避免带宽的浪费。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的报文冗余度调整方法流程图；

图2是本发明实施例提供的基于冗余度从大到小的顺序进行预算的报文冗余度调整方法流程图；

图3是本发明实施例提供的基于冗余度从小到大的顺序进行预算的报文冗余度调整方法流程图；

图4是本发明实施例提供的一种发送设备结构图；

图5是本发明实施例提供的另一种发送设备结构图；

图6是本发明实施例提供的又一种发送设备结构图；

图7是本发明实施例提供的带有定时器的发送设备结构图；

图8是本发明实施例提供的网络系统结构图。

具体实施方式

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，例如只读存储器，磁盘或光盘等。

参阅图1，本发明实施例提供一种报文冗余度调整方法，该方法包括：

101、获取发送端已向接收端发送的报文序列中各丢包事件的发生次数。

其中，本发明实施例各步骤的执行主体可以是发送端也可以是接收端。

其中，该步骤中的报文序列中各丢包事件可以包括：丢1个包事件、丢2个包事件、丢3个包事件、丢4个包事件等。其中，丢1个包事件是该事件发生时只丢失一个有效业务包；丢2个包事件是该事件发生时连续丢失2个有效业务包；丢3个包事件是该事件发生时连续丢失3个有效业务包；丢4个包事件是该事件发生时连续丢失4个有效业务包。其中，本发明各实施例中的丢i个包事件是指丢i个有效业务包的事件。

该步骤具体可以是：发送端利用特定冗余度向接收端发送所述报文序列，获取接收端上报的所述报文序列中各丢包事件的发生次数；其中，所述特定冗余度可以为0，即发送端在不进行丢包补偿的情况下发送所述报文序列，该特定冗余度也可以是1、2等值。

其中，对于RFC2198协议，冗余度是发送端允许的每个RTP报文中携带的冗余包的个数；对于RFC2733协议，冗余度表示前向纠错方式，冗余度为1表示的前向纠错方式能够补偿丢1个包事件；冗余度为2表示的前向纠错方式能够补偿丢2个包事件；冗余度为3表示的前向纠错方式能够补偿丢3个包事件；冗余度为4表示的前向纠错方式能够补偿丢4个包事件。其中，采用冗余度为1表示的前向纠错方式的报文发送序列可以为：a、b、f(a，b)、c、d、f(c，d)；采用冗余度为2表示的前向纠错方式的报文发送序列可以为：a、f(a，b)、b、f(b，c)、c、f(c，d)、d；采用冗余度为3表示的前向纠错方式的报文发送序列可以为：a、b、f(a，b，c)、c、f(a，c，d)、f(a，b，d)、d，其中，上述各报文发送序列中的a、b、c、d是有效业务包，f(a，b)、f(b，c)、f(c，d)、f(a，b，c)、f(a，c，d)、f(a，b，d)为冗余包。

102、根据各丢包事件的发生次数，确定待使用的冗余度，其中，待使用的冗余度是能使所述报文序列的丢包率满足丢包要求的冗余度中最小的冗余度。

其中，满足丢包要求可以是小于预置的丢包门限；所述报文序列的丢包率是各丢包事件导致的丢包率之和。

由于如果发送端向接收端发出的报文序列中的丢包事件仅仅只是“丢1个包事件”，那么即使未进行丢包补偿时总的丢包率(即各丢包事件的丢包率之和)再大，采用冗余度为1的补偿方式也可以保证补偿后总的丢包率为0，这时，即使采用冗余度为2或者冗余度为3的补偿方式，也没有任何意义，反而会浪费带宽。基于这个考虑，该步骤确定的待使用冗余度是丢包率之和满足丢包要求的冗余度中最小的冗余度。

其中，该步骤102具体可以采用如下方式实现：根据各丢包事件的发生次数，从所述最大冗余度开始递减，逐个对冗余度执行判断步骤，所述判断步骤为判断采用冗余度补偿后的所述报文序列的丢包率是否满足丢包要求；将最小的能够满足所述丢包要求的冗余度确定为待使用的冗余度。其中，采用冗余度补偿后的所述报文序列的丢包率的计算步骤包括：对于丢i个包事件，当i大于冗余度j时，计算丢包数＝(i-j)*丢i个包事件的发生次数；根据大于j的各丢包事件的丢包数和所述报文序列中的有效业务包数，得到采用所述冗余度j补偿后的所述报文序列的丢包率。其中，具体的，可以先根据大于j的各丢包事件的丢包数和所述报文序列中的有效业务包数，求出大于j的各丢包事件的丢包率，然后求大于j的各丢包事件的丢包率之和，所述和为采用所述冗余度j补偿后的所述报文序列的丢包率；或者，先求大于j的各丢包事件的丢包数之和，用所述和除以所述报文序列中的有效业务包数，得到采用所述冗余度j补偿后的所述报文序列的丢包率。其中，从所述最大冗余度开始递减，逐个对冗余度执行判断步骤，表示从所述最大冗余度开始执行判断步骤，并不表示对所有冗余度都执行该判断步骤，可以在找到所述待使用的冗余度后就停止判断步骤。

103、控制发送端利用所述待使用的冗余度向接收端发送报文。

其中，如上所述，本发明实施例各步骤的执行主体可以是发送端也可以是接收端，如果执行主体的发送端，则步骤103中发送端直接利用所述待使用的冗余度向接收端发送报文；如果执行主体是接收端，则步骤103中接收端向发送端返回标识待使用的冗余度的指示信息，发送端接收到该指示信息后，利用所述待使用的冗余度向接收端发送报文。

可选的，步骤101、步骤102和步骤103可以是周期执行的，即每隔预定周期就执行步骤101、步骤102和步骤103，以便根据传输环境及时的调整冗余度。即可以在周期时间到达时，发送端利用特定冗余度向接收端发送用于测试的报文序列，然后获取接收端上报的该用于测试的报文序列中各丢包事件的发生次数，并根据各丢包事件的发生次数，确定待使用的冗余度；可选的，也可以在周期时间到达时，发送端不发送用于测试的报文序列，而是直接利用特定冗余度向接收端发送通话过程中需要传输的数据报文序列，比如RTP报文序列，获取接收端上报的该报文序列中各丢包事件的发生次数。

可选的，步骤101、步骤102和步骤103也可以在丢包率大于或等于丢包门限时执行，即当判断得到报文序列当前的丢包率大于或等于丢包门限时，则执行步骤101、步骤102和步骤103，以便在传输环境恶化时及时调整冗余度，保证业务传输的质量。

本发明实施例根据报文序列中各丢包事件的发生次数，确定能使该报文序列的丢包率满足丢包要求的冗余度中最小的冗余度为待使用的冗余度，然后控制发送端利用所述待使用的冗余度向接收端发送报文。由于采用该待使用的冗余度补偿后的丢包率满足丢包要求，所以能够保证业务质量；由于发送端待使用的冗余度是满足丢包要求的冗余度中最小的冗余度，因此，可以使业务传输需要的带宽减小，避免带宽的浪费。

为了使本发明实施例提供的技术方案更加清楚，如下实施例对本发明实施例提供的技术方案进行详细介绍：

参阅图2，本发明实施例提供一种报文冗余度调整方法，该方法以符合RFC2198协议的RTP报文为例，按照冗余度从大到小的顺序预算各事件的丢包率之和，该方法具体包括：

201、呼叫建立时，发送端确定最大冗余度以及当前业务的丢包门限。

其中，丢包门限是由当前业务的类型决定的，一般来说，实时语音、视频业务的丢包门限为1％，实时数据业务的丢包门限为0％。

其中，最大冗余度是发送端允许的最大的冗余度。最大冗余度一般预置在产品中，不同型号的产品的最大冗余度可以不同。

202、呼叫开始中，发送端不采用丢包补偿方式，直接向接收端发送RTP报文序列。

该步骤中，发送端采用的冗余度为0。

203、接收端根据接收的RTP报文的序列号，确定该RTP报文序列中的各丢包事件的发生次数，向发送端上报实时传输控制协议(Real-TimeTransportControlProtocol，简称“RTCP”)报文，该RTCP报文中携带各丢包事件的发生次数，发送端根据该RTCP报文，获得网络环境的预测结果，其中，网络环境的预测结果包括各丢包事件的发生次数、该RTP报文序列中总丢包率等。

其中，RTP协议和RTCP协议是配合使用的，RTP协议用于传输业务报文，RTCP协议用于监控和反馈RTP报文在IP网络上的传输情况，在呼叫进行过程中，接收端会定期向发送端反馈RTCP报文。

其中，由于每个RTP报文具有唯一的序列号，该步骤中接收端根据所接收的RTP报文的序列号，可以确定各丢包事件的发生次数，比如发送端发出的RTP报文序列中的RTP报文有10个，序列号分别为1-10，则如果接收端接收到的RTP报文序列号为：1、2、3、5、8、10，则由于接收端没有接收到序列号为4的RTP报文、序列号为6的RTP报文、序列号为7的RTP报文、序列号为9的RTP报文，则接收端可以确定这个报文序列中丢1个包事件的发生次数为2次(即一个丢1个包事件为丢序列号为4的RTP报文，另一个丢1个包事件为丢序列号为9的RTP报文)，丢2个包事件的发生次数为1次(即丢序列号为6的RTP报文和丢序列号为7的RTP报文)。

可选的，该RTCP报文中还可以携带各丢包事件导致的丢包数，各丢包事件导致的丢包率、RTP报文序列中的总丢包数等。

其中，现有的RTCP报文中包括：累计报文丢失数(cumulativenumberofpacketslost)字段、扩展的接收最高序列号(extendedhighestsequencenumberreceived)字段和草案特有扩展(profile-specificextensions)字段；其中，累计报文丢失数字段标识一段时间段内的总丢包数，本实施例中假定该时间段内传输上述RTP报文序列，则累计报文丢失数字段标识上述RTP报文序列中的总丢包数；扩展的接收最高序列号字段标识该丢包统计截止的序列号。本发明实施例扩展了草案特有扩展字段，在草案特有扩展字段中携带了各丢包事件的发生次数，可选的，其还可以携带各丢包事件导致的丢包数，各丢包事件导致的丢包率等。

204、发送端判断定时器是否超时，如果是，则执行步骤205，如果否，执行步骤211。

其中，发送端预置定时器的时长，当定时器超时则表示到达发送端调整冗余度的时刻。

205、发送端设置冗余度j＝最大冗余度N。

该冗余度j为待预测丢包率的冗余度。

206、发送端预算采用冗余度j补偿后，各丢包事件的丢包率之和，比较各丢包事件的丢包率之和是否小于丢包门限，如果是，执行步骤207；如果否，执行步骤210。

其中，预算采用冗余度j补偿后，各丢包事件的丢包率之和的具体过程包括：对于丢i个包事件，当i大于冗余度j时，计算丢包数＝(i-j)*丢i个包事件的发生次数；先根据大于j的各丢包事件的丢包数和该RTP报文序列中的有效业务包数，求出大于j的各丢包事件的丢包率，然后求大于j的各丢包事件的丢包率之和；或者，先求大于j的各丢包事件的丢包数之和，用该和除以该RTP报文序列中的有效业务包数，得到各丢包事件的丢包率之和。

207、发送端判断j是否等于0，如果是，执行步骤208，如果否，执行步骤209。

208、发送端确定冗余度0为待使用的冗余度，执行步骤211。

209、发送端设置j＝j-1，返回执行步骤206。

210、当j不是最大冗余度时，发送端确定j+1为待使用的冗余度，当j是最大冗余度时，发送端确定j为待使用的冗余度。

211、发送端判断当前进行的呼叫业务是否结束，如果否，执行步骤212，如果是，结束本流程。

212、发送端利用所述待使用的冗余度向接收端发送RTP报文。

需要说明的是，在下一次定时器超时时，发送端不采用任何丢包补偿方式(即，此时冗余度为0)，直接向接收端发送需传输的RTP报文序列，重复执行步骤205-步骤212。

本发明实施例发送端根据RTP报文序列中各丢包事件的发生次数，按照冗余度从大到小的方式，预算补偿后的各丢包事件的丢包率之和，并根据预算结果，确定发送端待使用的冗余度，其中，发送端待使用的冗余度是丢包率之和小于丢包门限的冗余度中最小的冗余度。由于后续发送的RTP报文采用该冗余度补偿后的丢包率小于丢包门限，所以能够保证业务质量；由于该冗余度是满足小于丢包门限的冗余度中最小的冗余度，因此，可以使业务传输需要的带宽减小，避免带宽的浪费。

为了使上述实施例更加清楚，如下举实例进行说明：

假定步骤203中接收端发送的RTP报文序列时丢1个包事件的发生次数为3516次、丢2个包事件的发生次数为531次、丢3个包事件的发生次数为105次、丢4个包事件的发生次数为15次，则发送根据各丢包事件的发生次数，可以得到网络环境的测试结果，网络环境的测试结果具体包括：各丢包事件的发生次数、各丢包事件导致的丢包数、各丢包事件导致的丢包率、总的丢包率、各丢包事件占总丢包事件的概率等，其中，各丢包事件的发生次数、各丢包事件导致的丢包数、各丢包事件导致的丢包率、总的丢包率、各丢包事件占总丢包事件的概率分别是基于一段时间段内接收的报文得到的，本发明实施例中假定该段时间内传输上述RTP报文序列，则各丢包事件的发生次数、各丢包事件导致的丢包数、各丢包事件导致的丢包率、总的丢包率、各丢包事件占总丢包事件的概率分别是：上述RTP报文序列中各丢包事件的发生次数、各丢包事件导致的丢包数、各丢包事件导致的丢包率、总的丢包率、各丢包事件占总丢包事件的概率。

具体数值如下表1所示。

表1

假定当前进行的呼叫业务的丢包门限为3％，一旦出现丢包后，也不需要将丢包率补偿到0，只要进行丢包补偿后各丢包事件的总丢包率小于丢包门限即可。

对于上述网络环境的测试结果，考虑采用余度为4的方式进行补偿，在冗余度为4的方式进行补偿后，丢包率为0；再考虑采用余度为3的方式进行补偿，在冗余度为3的方式进行补偿时，对于丢1个包事件、丢2个包事件和丢3个包事件导致的丢包都可以进行补偿，对于丢4个包事件导致的丢包中，补偿了3个包，还有1个包没有得到补偿，则采用冗余度为3的方式进行补偿后，丢包数为15，丢包率为15/30000，可见，该丢包率小于丢包门限。再考虑采用余度为2的方式进行补偿，在冗余度为2的方式进行补偿时，对于丢1个包事件、丢2个包事件导致的丢包都可以进行补偿，对于丢3个包事件导致的丢包中，补偿了2个包，还有1个包没有得到补偿，对于丢4个包事件导致的丢包中，补偿了2个包，还有2个包没有得到补偿，这样，丢3个包事件导致的丢包数为105，丢4个包事件导致的丢包数为30，则总丢包率为(105+30)/30000，可见，总丢包率小于丢包门限；再考虑采用余度为1的方式进行补偿，在冗余度为1的方式进行补偿后，对于丢1个包事件所引起的丢包都能够得到补偿；对于丢2个包事件，补偿了1个包，还有1个包没有得到补偿；对于丢3个包事件，补偿了1个包，还有2个包没有得到补偿。对于丢4个包事件：补偿了1个包，还有3个包没有得到补偿。如下表2所示，对于丢1个包事件，采用冗余度为1的方式进行补偿后的总丢包个数为531个；对于丢2个包事件，采用冗余度为1的方式进行补偿后的总丢包个数为210个；对于丢3个包事件，采用冗余度为1的方式进行补偿后的总丢包个数为45个；则采用冗余度为1的方式进行补偿后的各丢包事件导致的总丢包个数为786。可见采用冗余度为1的方式进行补偿后，丢1个包事件导致的丢包率为0％，丢2个包事件导致的丢包率为1.77％，丢3个包事件导致的丢包率为0.70％，丢个包事件导致的丢包率为0.15％，则各丢包事件导致的丢包率之和为2.62％，其小于3％，所以采用冗余度为1的补偿方式就可以保证业务质量。

表2

参阅图3，本发明实施例提供又一种报文冗余度调整方法，该方法以符合RFC2198协议的RTP报文为例，按照冗余度从小到大的顺序预算各事件的丢包率之和，该方法具体包括：

步骤301-303与步骤201-203相同，在此不再赘述。

304、发送端判断定时器是否超时，如果是，则执行步骤305，如果否，执行步骤310。

305、发送端设置冗余度j＝0。

在另一种可选的实施方式中，发送端可以设置冗余度j＝1。

306、发送端预算采用冗余度j补偿后，各丢包事件的丢包率之和，比较各丢包事件的丢包率之和是否大于或者等于丢包门限，如果是，执行步骤307；如果否，执行步骤309。

其中，预算采用冗余度j补偿后，各丢包事件的丢包率之和的具体过程与步骤305相似，在此不再赘述。

307、j＝j+1。

308、发送端判断j是否等于N，如果否，返回执行步骤306；如果是，执行步骤309。

309、发送端确定冗余度j为待使用的冗余度。

步骤310-311与步骤211-212相同，在此不再赘述。

本发明实施例发送端根据RTP报文序列中各丢包事件的发生次数，按照冗余度从小到大的方式，预算补偿后的各丢包事件的丢包率之和，并根据预算结果，确定发送端待使用的冗余度，其中，发送端待使用的冗余度是丢包率之和小于丢包门限的冗余度中最小的冗余度。由于后续发送的RTP报文采用该冗余度补偿后的丢包率之和小于丢包门限，能够保证业务质量；由于该冗余度是满足小于丢包门限的冗余度中最小的冗余度，因此，可以使业务传输需要的带宽减小，避免带宽的浪费。

参阅图4，本发明一实施例提供一种发送设备，其包括：

获取单元10，用于获取所述发送设备已向接收设备发送的报文序列中各丢包事件的发生次数；

冗余度确定单元20，用于根据各丢包事件的发生次数，确定待使用的冗余度，其中，待使用的冗余度是能使所述报文序列的丢包率满足丢包要求的冗余度中最小的冗余度；其中，满足丢包要求可以是小于预定的丢包门限。

发送单元30，用于利用所述待使用的冗余度向所述接收设备发送报文。

其中，所述获取单元10具体用于利用特定冗余度向接收设备发送所述报文序列，并获取所述接收设备上报的所述报文序列中各丢包事件的发生次数。其中，特定冗余度可以为0或者其他值，不影响本发明的实现。

如图5所示，冗余度确定单元20具体可以包括：判断单元21，用于根据各丢包事件的发生次数，从所述最大冗余度开始递减，逐个对冗余度执行判断步骤，所述判断步骤为判断采用冗余度补偿后的所述报文序列的丢包率是否满足丢包要求；和确定单元22，用于将最小的能够满足所述丢包要求的冗余度确定为待使用的冗余度。

如图6所示，上述判断单元21具体可以包括：丢包率获取子单元23，用于根据各丢包事件的发生次数，从所述最大冗余度开始递减，逐个对冗余度执行如下操作：对于丢i个包事件，当i大于冗余度j时，计算丢包数＝(i-j)*丢i个包事件的发生次数；根据大于j的各丢包事件的丢包数和所述报文序列中的有效业务包数，得到采用所述冗余度j补偿后的所述报文序列的丢包率；和判断子单元24，用于判断采用冗余度j补偿后的所述报文序列的丢包率是否满足丢包要求。其中，具体的根据大于j的各丢包事件的丢包数和所述报文序列中的有效业务包数，得到采用所述冗余度j补偿后的所述报文序列的丢包率的实现方式与方法实施例相似，在此不再赘述。

如图7所示，在一种具体实施方式中，该发送设备还包括：定时器40，用于在定时时间到达时，触发所述获取单元利用特定冗余度向接收设备发送所述报文序列。其中，该报文序列可以是用于测试的报文序列，也可以是发送设备与接收设备之间需要传输的报文序列，比如RTP报文序列，不影响本发明的实现；其中，发送单元30所发送的报文是发送设备与接收设备之间需要传输的RTP报文。

本发明实施例冗余度确定单元根据报文序列中各丢包事件的发生次数，确定能使该报文序列的丢包率满足丢包要求的冗余度中最小的冗余度为待使用的冗余度，然后发送单元利用所述待使用的冗余度向所述接收设备发送报文。由于采用该冗余度补偿后的丢包率满足丢包要求，所以能够保证业务质量；由于该冗余度是满足丢包要求的冗余度中最小的冗余度，因此，可以使业务传输需要的带宽减小，避免带宽的浪费。

参阅图8，本发明实施例提供一种网络系统，其包括：发送设备50和接收设备60，其中，

发送设备50，用于获取发送设备50已向接收设备60发送的报文序列中各丢包事件的发生次数；根据各丢包事件的发生次数，确定待使用的冗余度，其中，待使用的冗余度是能使所述报文序列的丢包率满足丢包要求的冗余度中最小的冗余度；利用所述待使用的冗余度向接收设备60发送报文；

接收设备60，用于接收所述发送设备50发送的所述报文序列和所述报文，向所述发送设备上报所述报文序列中各丢包事件的发生次数。

其中，具体的发送设备的结构和功能可以与上述图4至图7所示实施例的发送设备的结构和功能相同，在此不再赘述。

本发明实施例中发送设备根据报文序列中各丢包事件的发生次数，确定能使该报文序列的丢包率满足丢包要求的冗余度中最小的冗余度为待使用的冗余度，然后利用所述待使用的冗余度向接收设备发送报文。由于采用该冗余度补偿后的丢包率满足丢包要求，所以能够保证业务质量；由于该冗余度是满足丢包要求的冗余度中最小的冗余度，因此，可以使业务传输需要的带宽减小，避免带宽的浪费。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，例如只读存储器，磁盘或光盘等。

以上对本发明实施例所提供的报文冗余度调整方法、相关设备及网络系统进行了详细介绍，本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其核心思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims (8)

1.一种报文冗余度调整方法，其特征在于，包括：

获取发送端已向接收端发送的报文序列中各丢包事件的发生次数；

根据各丢包事件的发生次数，确定待使用的冗余度，其中，待使用的冗余度是能使所述报文序列的丢包率满足丢包要求的冗余度中最小的冗余度；

控制发送端利用所述待使用的冗余度向接收端发送报文；

其中，采用冗余度补偿后的所述报文序列的丢包率的计算步骤包括：

对于丢i个包事件，当i大于冗余度j时，计算丢包数＝(i-j)*丢i个包事件的发生次数，所述丢i个包事件指的是该事件发生时，连续丢失i个有效业务包；

根据大于j的各丢包事件的丢包数和所述报文序列中的有效业务包数，得到采用所述冗余度j补偿后的所述报文序列的丢包率。

2.根据权利要求1所述的方法，其特征在于，

获取发送端已向接收端发送的报文序列中各丢包事件的发生次数包括：

发送端利用特定冗余度向接收端发送所述报文序列，并获取接收端上报的所述报文序列中各丢包事件的发生次数。

3.根据权利要求1所述的方法，其特征在于，根据各丢包事件的发生次数，确定待使用的冗余度，包括：

根据各丢包事件的发生次数，从最大冗余度开始递减，逐个对冗余度执行判断步骤，所述判断步骤为判断采用冗余度补偿后的所述报文序列的丢包率是否满足丢包要求；将最小的能够满足所述丢包要求的冗余度确定为待使用的冗余度。

4.根据权利要求1所述的方法，其特征在于，每隔预定周期，执行各个步骤。

5.一种发送设备，其特征在于，包括：

获取单元，用于获取所述发送设备已向接收设备发送的报文序列中各丢包事件的发生次数；

冗余度确定单元，用于根据各丢包事件的发生次数，确定待使用的冗余度，其中，待使用的冗余度是能使所述报文序列的丢包率满足丢包要求的冗余度中最小的冗余度；

发送单元，用于利用所述待使用的冗余度向所述接收设备发送报文；

所述冗余度确定单元包括：

判断单元，用于根据各丢包事件的发生次数，从最大冗余度开始递减，逐个对冗余度执行判断步骤，所述判断步骤为判断采用冗余度补偿后的所述报文序列的丢包率是否满足丢包要求；

确定单元，用于将最小的能够满足所述丢包要求的冗余度确定为待使用的冗余度；

所述判断单元包括：

丢包率获取子单元，用于根据各丢包事件的发生次数，从所述最大冗余度开始递减，逐个对冗余度执行如下操作：对于丢i个包事件，当i大于冗余度j时，计算丢包数＝(i-j)*丢i个包事件的发生次数；根据大于j的各丢包事件的丢包数和所述报文序列中的有效业务包数，得到采用所述冗余度j补偿后的所述报文序列的丢包率，所述丢i个包事件为该事件发生时连续丢失i个有效业务包；

判断子单元，用于判断采用冗余度j补偿后的所述报文序列的丢包率是否满足丢包要求。

6.根据权利要求5所述的发送设备，其特征在于，

所述获取单元，用于利用特定冗余度向接收设备发送所述报文序列，并获取所述接收设备上报的所述报文序列中各丢包事件的发生次数。

7.根据权利要求5所述的发送设备，其特征在于，还包括：

定时器，用于在定时时间到达时，触发所述获取单元利用特定冗余度向接收设备发送所述报文序列。

8.一种网络系统，其包括：权利要求5-7任一项所述的发送设备，以及接收设备，

所述接收设备，用于接收所述发送设备发送的所述报文序列和所述报文；向所述发送设备上报所述报文序列中各丢包事件的发生次数。