CN102845008A

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

Info

Publication number: CN102845008A
Application number: CN2011800002675A
Authority: CN
Inventors: 胡国杰
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2011-04-25
Filing date: 2011-04-25
Publication date: 2012-12-26
Anticipated expiration: 2031-04-25
Also published as: CN102845008B; WO2011110130A3; WO2011110130A2

Abstract

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

Description

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

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

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

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

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

其中， 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, 形成完整的报文序列 RTPI、 RTP2、 RTP3

其中， RFC2733 协议定义的冗余机制的基本原理是：在发送报文序列中增加携带前向纠错 (Forward Error Correction, 筒称" 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)异或恢复(。

使用 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-Time Transport Control Protocol, 筒称 "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个包事件的发生次数为次（即一个丢 1个包事件为丢序列号为 4的 RTP报文，另一个丢 1个包事件为丢序列号为 9的 RTP报文），丢 2个包事件的发生次数为 1次 (即丢序列号为 6的 RTP报文和丢序列号为 7的 RTP报文）。

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

其中，现有的 RTCP报文中包括：累计报文丢失数（ cumulative number of packets lost )字段、扩展 ό 接 4史最高序歹 l)号 ( extended highest sequence number received )字段和草案特有扩展 ( profile- specific extensions )字段；其中，累计报文丢失数字段标识一段时间段内的总丢包数，本实施例中假定该时间段内传输上述 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-l , 返回执行步骤 206。

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

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

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

需要说明的是，在下一次定时器超时时，发送端不采用任何丢包补偿方式

(即，此时冗余度为 0 ), 直接向接收端发送需传输的 RTP报文序列，重复执行步骤 205-步骤 212。

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

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

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

具体数值如下表 1所示。

表 1

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

对于上述网络环境的测试结果，考虑采用余度为 4的方式进行补偿，在冗余度为 4的方式进行补偿后，丢包率为 0; 再考虑采用余度为 3的方式进行补偿，在冗余度为 3的方式进行补偿时，对于丢 1个包事件、丢 2个包事件和丢 3个包事件导致的丢包都可以进行补偿，对于丢 4个包事件导致的丢包中，补偿了 3个包，还有 1个包没有得到补偿，则采用冗余度为 3的方式进行补偿后，丢包数为 15 , 丢包率为 15/ 30000 , 可见，该丢包率小于丢包门限。再考虑采用余度为 2的方式进行补偿，在冗余度为 1的方式进行补偿时，对于丢 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的补偿方式就可以保证业务质量。

冗余度为 1的

冗余度为 1的丢包事方式进行补

事件数丢包数丢包率方式进行补偿件概率偿后的丢包

后的丢包率数

丢 1个包事件 3516 3516 84.38% 11.72% 0 0.00%

丢 2个包事件 531 1062 12.74% 3.54% 531 1.77%

丢 3个包事件 105 315 2.52% 1.05% 210 0.70%

丢 4个包事件 15 60 0.36% 0.20% 45 0.15%

总丢包事件 4167

总不丢包事件 25047

总丢包数 4953

总发包数 30000

总丢包率 16.51%

表 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+l。

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

权利要求

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

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

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

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

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

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

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

4、根据权利要求 3所述的方法，其特征在于，采用冗余度补偿后的所述报文序列的丢包率的计算步骤包括：

对于丢 i个包事件，当 i大于冗余度 j时，计算丢包数 = ( i-j ) *丢 i个包事件的发生次数；

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

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

6、一种发送设备，其特征在于，包括：

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

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

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

7、根据权利要求 6所述的网络设备，其特征在于，

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

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

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

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

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

9、根据权利要求 8所述的发送设备，其特征在于，

所述判断单元包括：

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

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

10、根据权利要求 6所述的发送设备，其特征在于，还包括：

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

11、一种网络系统，其包括：权利要求 6-10所述的发送设备，以及接收设备，

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