CN103167430A - 一种彩铃系统性能评估的方法和系统 - Google Patents

Abstract

本发明公开了一种彩铃系统性能评估的方法和系统，业务数据采集子系统收集彩铃系统数据或者期待验证的性能数据；性能分析子系统进行数据分析，并将输出结果导出给数据显示子系统；数据显示子系统根据业务数据采集子系统收集的性能数据，结合性能分析子系统预设的性能原型，以数据表的形式展现系统各部件及子部件的负荷情况。采用了本发明的技术方案，能够实时分析彩铃系统的数据，并且系统负荷的统计方法更加精准，能准确找到最大的系统负荷，避免错误的统计方法导致系统负荷虚高。

Description

一种彩铃系统性能评估的方法和系统

技术领域

本发明涉及增值语音业务技术领域，尤其涉及一种彩铃系统性能评估的方法和系统。

背景技术

为了提升网络质量，通信运营商都采取网络维护和优化处理，如图1所示，当前彩铃系统日常的运行状况的观察依赖于现有统计方法，性能测量、查询测量结果是个静态的事后过程，不能提前预判系统能够承载的负荷。另一方面，性能测量查询结果的数据呈现方式比较单一，基本上没有对数据的再加工呈现，也无法完成类似过门限提示、趋势分析、关联明细数据分析等丰富多变的用户需求。

彩铃作为成熟的电信增值业务，针对日常运营的实际需要，迫切需要一种准确的统计方法优化对现有的彩铃系统的接入设备的性能评估，动态掌握系统的运行状态，了解系统的各种负荷上限，优化设备配置组合，节省资金投入，提升服务质量。

然而当前的技术方案主要存在以下不足：

(1)缺少主动收集性能数据的功能，目前其它类似功能的工具采用被动收集功能，数据的收集都是由被分析系统上报，无法做到实时收集实时分析；

(2)基于现有的统计方法，会导致系统分析的精准度不高，容易导致系统容量“虚高”。

发明内容

本发明的目的是针对现有技术方案中彩铃系统的性能分析无法实时开展、并且精确度不高的问题，而提出的一种彩铃系统性能评估的方法和系统，能够实时分析彩铃系统的数据，并且系统负荷的统计方法更加精准，能准确找到最大的系统负荷，避免错误的统计方法导致系统负荷虚高。

为实现本发明的目的，采用了以下技术方案：

本发明的一个具体实施方式提供了一种彩铃系统性能评估的方法，包括以下步骤：

A、收集不少于两个时段的彩铃呼叫话务量Erl和对应时段内的平均放音时长，抽取其中数值最大的彩铃呼叫话务量Erl作为彩铃系统承载的最大话务量Erl；

B、将所述彩铃系统承载的最大话务量Erl与对应时段内的平均放音时长之商作为彩铃系统忙时并发呼叫数Caps；

C、采用以下公式获得内部通道数：

内部通道数＝彩铃系统忙时并发呼叫数Caps×所有时段的平均放音时长/(1-业务呼损率)；

D、采用以下公式获得信令链路数：

信令链路数＝Max(2，2×Roundup(彩铃系统忙时并发呼叫数Caps×呼叫消息数×每呼叫消息字节数×信令链路双向不均衡系数×8/(信令物理接口比特数×信令链路承载比例值)，0))，其中Roundup是向上取整函数，Max是取最大值函数。

优选地，所述业务呼损率是0.005。

优选地，所述呼叫消息数是5。

优选地，所述每呼叫消息字节数是30Byte。

优选地，所述信令链路双向不均衡系数是1.6。

优选地，所述信令物理接口比特数是64Kbit或者2Mbit。

进一步地，如果信令物理接口比特数是64Kbit，所述信令链路承载比例值是0.4，；如果信令物理接口比特数是2Mbit，所述信令链路承载比例值是0.2。

优选地，所述信令链路不少于2条。

本发明的另一个具体实施方式提供了一种彩铃系统性能评估的系统，包括业务数据采集子系统、性能分析子系统和数据显示子系统，其中，

业务数据采集子系统用于收集彩铃系统数据或者期待验证的性能数据；

性能分析子系统用于进行数据分析，并将输出结果导出给数据显示子系统；

数据显示子系统用于根据业务数据采集子系统收集的性能数据，结合性能分析子系统预设的性能原型，以数据表的形式展现系统各部件及子部件的负荷情况。

所述业务数据采集子系统进一步包括人工交互模块、系统主动收集模块、彩铃系统接口调用模块、接入设备收集筛选模块、呼叫设备收集筛选模块、后台服务器设备数据收集筛选模块和彩铃系统接口数据收集分配模块，其中：

人工交互模块用于采用Web界面，提供给用户手工录入，收集彩铃用户数、忙时试呼次数BHCA、放音时长、彩铃用户开销户数和月下载设置数；

系统主动收集模块用于收集彩铃系统日常的运行信息、并实现数据导入和数据库接口调用；

彩铃系统接口调用模块用于采用标准的简单对象访问协议SOAP接口，访问彩铃系统的语音增值业务开发平台USDP，收集语音增值业务开发平台USDP系统接口并发调用次数和语音增值业务开发平台USDP日志信息；

接入设备收集筛选模块用于提取收集数据中，接入设备相关的信令数、中继数、忙时试呼次数BHCA和放音时长信息，提交给性能分析子系统；

呼叫设备收集筛选模块用于提取收集数据中，呼叫设备相关的忙时试呼次数BHCA和放音时长信息，提交给性能分析子系统；

后台服务器设备数据收集筛选模块用于提取收集数据中，彩铃后台业务语音增值业务开发平台USDP的相关信息，提交给性能分析子系统。

彩铃系统接口数据收集分配模块用于数据库接口调用，负责收集彩铃后台系统的运营信息，采用标准的JDBC接口调用，收集彩铃用户、彩铃用户开销户数和月下载设置数。

系统主动收集模块进一步包括数据导入单元和数据库接口调用单元，其中，

数据导入单元用于收集通用资源平台URP的话统数据；

数据库接口调用单元用于收集彩铃后台系统的运营信息，采用标准的JAVA数据库连接JDBC接口调用、收集彩铃用户、彩铃用户开销户数和月下载设置数。

所述性能分析子系统进一步包括性能逻辑分析模块、业务发展趋势分析和用户行为分析模块、业务故障数据分析模块和性能数据校验模块，其中，

性能逻辑分析模块用于对接入设备的性能进行分析；

业务发展趋势分析和用户行为分析模块用于根据业务数据采集子系统收集到的业务运行信息，进行用户喜好分析和业务功能使用分析；

业务故障数据分析模块用于根据业务数据采集子系统收集到的故障点数据信息，分析造成故障的原因，用于根据收集到的话务数据和业务使用量信息，分析故障点瞬时的业务波动信息，找到产生故障的网元信息；

性能数据校验模块用于根据业务数据采集子系统采集的用户期望验证的性能模型数据，结合当前系统实际可承受的业务量，找出当前系统存在的瓶颈，作为扩容的依据.

所述性能逻辑分析模块进一步包括URP性能分析单元、呼叫控制部件性能分析单元和数据库性能分析单元，其中，

URP性能分析单元用于分析当前系统URP信令和媒体资源的负荷情况；

呼叫控制部件性能分析单元用于分析当前系统CTI部件的信令处理负荷、活动呼叫数和呼叫处理时延，并评估当前CTI系统的负荷情况；

数据库性能分析单元用于分析当前业务系统用户业务操作量、系统并发访问量和后台定时任务处理时长，并评估当前数据库的负荷情况。

所述业务发展趋势分析和用户行为分析模块进一步包括用户喜好分析单元、业务功能使用分析单元、用户发展趋势单元和用户消费趋势单元，其中，

用户喜好分析单元用于根据业务数据采集子系统收集到的用户下载、设置信息，找到用户的喜爱和偏好；

业务功能使用分析单元用于根据数据收集模块收集到的开销户数、铃音定购数和用户下载设置信息，分析当前系统业务使用情况，分析当前彩铃系统后台系统的负荷情况；

用户发展趋势单元用于分析用户发展趋势；

用户消费趋势单元用于分析用户消费趋势。

所述业务故障数据分析模块进一步包括URP故障分析单元、呼叫控制部件故障分析单元和数据库及后台业务故障分析单元，其中，

URP故障分析单元用于根据收集到的故障点话务数据，分析信令、资源各子部件的业务负荷量，结合当前系统可承载的业务量，进行数据对比，找出引起故障点的子系统；

呼叫控制部件故障分析单元用于根据收集到的故障点话务数据，分析当前系统CTI部件的信令处理负荷、活动呼叫数和呼叫处理时延信息，结合当前呼叫控制部件可承载的业务量，进行对比，评估呼叫控制部件是否为故障根源；

数据库及后台业务故障分析单元用于根据收集到的故障点后台业务使用信息，结合当前业务系统可承载的业务量，进行数据对比，找出产生故障的网元信息。

所述性能数据校验模块进一步包括URP性能校验单元、呼叫控制部件性能校验单元和数据库及后台业务性能校验单元，其中，

URP性能校验单元用于根据业务数据采集子系统传递的性能模型数据，分别验证信令和资源两个模块，如果当前系统无法承载所述性能模型，则所述URP性能校验单元提示用户具体存在瓶颈的子系统名称，并给出扩容意见；

呼叫控制部件性能校验单元用于根据业务数据采集子系统传递的性能模型数据，验证CTI系统是否可以承载所述性能模型，如果CTI系统无法承载所述性能模型，则所述呼叫控制部件性能校验单元给出扩容意见；

数据库及后台业务性能校验单元用于根据业务数据采集子系统传递的性能模型数据，验证整个彩铃后台系统是否可以承载所述性能模型，如果彩铃后台系统无法承载所述性能模型，则数据库及后台业务性能校验单元给出扩容意见。

采用本发明的技术方案，具有以下技术效果：

(1)系统负荷的统计方法更加精准，能准确找到最大的系统负荷，避免错误的统计方法导致系统负荷虚高。

(2)主动的系统收集功能，不是被动的接收数据，系统数据可以做到实时分析。

(3)作为彩铃系统专属的性能分析工具，更加贴近业务，使系统性能分析做到精准，系统分析细化到各模块的子部件。

(4)丰富的信息收集渠道，通过调用系统接口、访问数据库接口，实时分析业务发展趋势以及用户的操作行为变化。

(5)良好的数据校验功能，预知系统安全运行底线，方便使用者提前做好各种应对措施

(6)快速的“事后”定位功能，快速找到系统问题根因

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。本发明的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。

下面通过附图和实施方式，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施方式一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1是现有技术中网络维护和优化处理的流程图。

图2是本发明具体实施方式一中彩铃系统性能评估的流程图。

图3是本发明具体实施方式二中彩铃系统性能评估系统的结构示意图。

图4是本发明具体实施方式二中业务数据采集子系统的结构示意图。

图5是本发明具体实施方式二中性能分析子系统的结构示意图。

具体实施方式

以下结合附图对本发明的优选实施方式进行说明，应当理解，此处所描述的优选实施方式仅用于说明和解释本发明，并不用于限定本发明。

图2是本发明具体实施方式一中彩铃系统性能评估的流程图。如图2所示，该彩铃系统性能评估流程包括以下步骤：

以某地市收集的话统数据为例，进行分析：

步骤201、收集每天多个时段(例如每个小时收集一次)的彩铃呼叫话务量Erl和对应时段内的平均放音时长，抽取其中数值最大的彩铃呼叫话务量Erl作为彩铃系统承载的最大话务量Erl。

通过观察可以发现彩铃业务的特点是，凌晨以后，系统放音时长变大，而并发呼叫次数很少，白天呼叫次数较多，但放音时长较短。因此单纯的根据最大呼叫次数，最大的平均放音时长来计算URP能力，会导致准确性差，因此需要根据最大Erl作为系统建设参考，因此会发现系统最大Erl出现在19:00这个时段。

步骤202、将彩铃系统承载的最大话务量Erl与对应时段内的平均放音时长之商作为彩铃系统忙时并发呼叫数Caps，即采用以下公式：

彩铃系统忙时并发呼叫数Caps＝Max(多个时段的彩铃呼叫话务量Erl)/对应时段的平均放音时长。

步骤203、采用以下公式获得内部通道数：

内部通道数＝彩铃系统忙时并发呼叫数Caps×所有时段的平均放音时长/(1-业务呼损率)，其中，业务呼损率是0.005。

基于电路交换的特点是，内部媒体资源通道和外部通道的比例要保持1∶1，但出于系统安全性等考虑，内部资源在实际建设时要比外部通道数多，考虑0.005的业务呼损率，因此内部通道数实际计算时比外部通道数要多。

步骤204、采用以下公式获得信令链路数：

信令链路数＝Max(2，2×Roundup(彩铃系统忙时并发呼叫数Caps×呼叫消息数×每呼叫消息字节数×信令链路双向不均衡系数×8/(信令物理接口比特数×信令链路承载比例值)，0))，

其中Roundup是向上取整函数，Max是取最大值函数，呼叫消息数是5，每呼叫消息字节数是30Byte，信令链路双向不均衡系数是1.6，信令物理接口比特数是64Kbit或者2Mbit，如果信令物理接口比特数是64Kbit，信令链路承载比例值是0.4，，如果信令物理接口比特数是2Mbit，信令链路承载比例值是0.2，信令链路建设时，至少部署2条，以保证系统可靠性。

采用上述公式，可以分析出该地市的彩铃系统的性能：

彩铃系统承载的最大话务量Erl＝Max(多个时段的彩铃呼叫话务量Erl)＝1918；

彩铃系统忙时并发呼叫数Caps＝Max(多个时段的彩铃呼叫话务量Erl)/对应时段的平均放音时长＝1918/14.41＝133；

内部通道数＝彩铃系统忙时并发呼叫数Caps×所有时段的平均放音时长/(1-业务呼损率)＝1918/0.995＝1928

信令链路数＝Max(2，2×Roundup(彩铃系统忙时并发呼叫数Caps×呼叫消息数×每呼叫消息字节数×信令链路双向不均衡系数×8/(信令物理接口比特数×信令链路承载比例值)，0))＝Max(2，2×Roundup(133×5×30Byte×1.6×8/(64000*0.4)，0)＝20。

根据上述URP负荷计算，可以看出如果现场负荷按照最大呼叫次数，以及最大通话时长统计，会导致整个系统的负荷虚高，而优化后的统计方法，会准确地统计到系统最大接入量，从而更准确地获取到系统实际的负荷。

系统建设时，资源通道和信令链路是重点关注的性能指标，作为一个稳定的系统，建设时一定要考虑一定的余量，因此优化后的资源通道以及信令链路计算公式将更加符合实际的需要，采用此种优化后的方法，系统会更加健壮。

通过上述彩铃系统的性能评估流程，能够准确获取到系统的负荷，准确获取到系统话务模型，为今后的扩容提供主要依据；预估整个系统的安全门限，了解每个子系统的安全阀值，制定相应的流控措施，合理挖掘系统潜能，提升系统安全性；针对升级、割接场景、重大事件、重大节假日运行保障。比如重要会议、运动会、庆祝活动、春节/中秋等等，能对系统进行动态分析，制定相应的应对策略；分析彩铃系统的统计数据，了解各节点的话务变化，对话务趋势做出提前预判，正确引导每个节点的扩容计划。

图3是本发明具体实施方式二中彩铃系统性能评估系统的结构示意图。如图3所示，该彩铃系统性能评估系统包括业务数据采集子系统、性能分析子系统和数据显示子系统。

业务数据采集子系统收集彩铃话务数据等系统数据，也可以是人为期待验证的性能数据，如果输入的数据是当前系统数据，则该工具将向使用者展现当前系统关键部件的实际负荷情况，如果输入的是人为期待验证的性能数据，则该工具将向使用者展现基于此种模型下系统关键部件的承受负荷。业务数据采集子系统具备如下技术特点：

(1)全自动的系统采集功能，比其它工具的技术优势主要体现如下几点：自动的数据采集，而不是被动接收业务系统反馈的信息，使系统可以做到实时分析；避免信息收集的单一性，现行系统因为是被动接收数据，无法深入到系统内部获取关键的信息，本系统可以收集业务的运营信息、用户行为信息等，可以通过调用系统接口、或查询数据库等手段，采集各种需要的信息，使得该系统可以全面的展示各种有用数据，对后期的分析提供有效的支撑。

(2)更加能贴近业务系统，因为该业务数据采集子系统是针对彩铃系统设计的，所以整体的数据收集更加侧重彩铃业务，使得收集的数据更加有针对性，而不是一个较为简单的数据收集能力。

(3)提供人工交互界面，可以人为触发各种校验功能，例如某个特殊时期，用户希望彩铃系统可以运行在超过警戒值的场景下，该工具为此功能提供了便利，用户通过交互界面输入期待验证的值，系统将会根据该值进行分析。

如图4所示，业务数据采集子系统进一步包括人工交互模块、系统主动收集模块、彩铃系统接口调用模块、接入设备收集筛选模块、呼叫设备收集筛选模块、后台服务器设备数据收集筛选模块和彩铃系统接口数据收集分配模块。

人工交互模块采用Web界面，提供给用户手工录入，收集彩铃用户数、忙时试呼次数BHCA、放音时长、彩铃用户开销户数和月下载设置数。

系统主动收集模块进一步包括数据导入单元和数据库接口调用单元，系统主动收集模块收集彩铃系统日常的运行信息，以此评估当前系统的负荷情况，主动收集系统提供数据导入、数据库接口调用等能力。

数据导入单元负责收集通用资源平台URP的话统数据。数据库接口调用单元负责收集彩铃后台系统的运营信息，采用标准的JDBC接口调用，收集如彩铃用户、彩铃用户开销户数、月下载设置数等信息。系统主动收集模块，采用定时任务，定期导入URP的话统文件，从话统文件中导出诸如BHCA、MHT等数据信息，该定时任务还定期调用数据库，通过查询用户表、下载设置表等获取到用户日常操作信息。

彩铃系统接口调用模块采用标准的简单对象访问协议SOAP接口，访问彩铃系统的语音增值业务开发平台USDP，收集语音增值业务开发平台USDP系统接口并发调用次数和语音增值业务开发平台USDP日志信息。

接入设备收集筛选模块提取收集数据中接入设备相关的信令数、中继数、忙时试呼次数BHCA和放音时长信息，提交给性能分析子系统。

呼叫设备收集筛选模块提取收集数据中呼叫设备相关的忙时试呼次数BHCA和放音时长信息，提交给性能分析子系统。

后台服务器设备数据收集筛选模块提取收集数据中彩铃后台业务语音增值业务开发平台USDP的相关信息，提交给性能分析子系统。

性能分析子系统进行数据分析，并将输出结果导出给数据显示子系统。性能分析子系统针对彩铃系统的各部件进行性能计算，该部件较其它系统具备以下技术特点：

(1)较其它被动分析系统，该性能分析子系统具备了实时数据分析功能，动态的计算各时期的系统部件负荷。

(2)作为彩铃系统的分析工具，更贴近业务系统，使用者能够精确了解到彩铃系统每个子部件的运行状态。

(3)精确的业务发展趋势分析，提前获悉到用户数发展趋势，以及用户业务使用习惯的变化，能让使用者尽快了解业务运行相关信息，真确的引导业务扩容，节约无谓的资金投入。

(4)具备网管系统所不具备的业务故障点分析功能，现有网管系统仅能上报告警信息，但无法深入分析业务系统产生故障的根因，本系统具备良好的“事后”分析功能，根据各种故障点收集到的信息，找到问题发生根源，能真确引导使用者找到系统中存在的不足。

(5)良好的数据校验功能，是使用者能够获悉系统安全运行底线，为突发事件提供超前预警功能。

如图5所示，性能分析子系统进一步包括性能逻辑分析模块、业务发展趋势分析和用户行为分析模块、业务故障数据分析模块和性能数据校验模块。

性能逻辑分析模块对接入设备的性能进行分析。性能逻辑分析模块进一步包括URP性能分析单元、呼叫控制部件性能分析单元和数据库性能分析单元。

URP性能分析单元分析当前系统URP信令和媒体资源的负荷情况。URP性能分析单元可以通过收集模块上报的话统数据推导URP信令处理单板MSU、媒体资源处理板VRB/MSU、外部中继接口板等单板的负荷占用情况。信令分析包含信令中继占用分析、信令并发请求消息数、信令处理板资源占用分析等。媒体资源分析包含媒体资源占用量分析、媒体中继负荷比例等。信令中继占用用于评估当前信令链路的占用情况。信令并发请求消息数用于评估当前并发呼叫量，通过并发呼叫量获悉当前呼叫消息总量，获悉当前彩铃系统和某一信令点的之间的消息交互带宽，评估当前信令链路上的流量负荷。媒体资源占用用于评估当前URP系统内部放音资源板的媒体通道使用率。媒体中继负荷用户评估URP中继接口板E1接口使用率。

呼叫控制部件性能分析单元分析当前系统CTI部件的信令处理负荷、活动呼叫数和呼叫处理时延，并以此评估当前CTI系统的负荷情况。CTI作为呼叫控制的核心部件，负责处理所有呼叫，并根据配置的接入号，执行对应的呼叫流程，CTI作为整个呼叫的处理中枢，并发的呼叫数以及呼叫通道数，都会对其产生一定的性能影响。通过数据收集模块收集到的呼叫信息数据，可以评估当前CTI系统的负荷，当前并发呼叫数用于评估CTI信令处理模块的处理负荷，活动呼叫数用于评估当前CTI并发在线用户数。

彩铃呼叫流程有管理IVR和彩铃播放两个业务场景。管理IVR流程涉及用户复杂的交互过程，因此在性能评估时按照通道数进行性能评估。彩铃播放流程，由于没有用户交互过程，采用标准的信令交互流程，整体执行效率较高，因此性能评估时按照并发呼叫Caps进行性能评估。

管理IVR设备数量＝管理流程通道数/单个设备可支持的最大通道数；

彩铃播放设备数量＝彩铃播放Caps/单个设备可支持的最大播放Caps。

数据库性能分析单元分析当前业务系统用户业务操作量、系统并发访问量和后台定时任务处理时长，并评估当前数据库的负荷情况。

本数据库性能分析单元采用国际标准的小型机处理能力的参数TPS作为计算单位，摆脱设备硬件多样性所导致的性能偏差的不定因素，提高计算准确性，为了更好的说明优势特举例说明：

设备商的一个系列机型，会有多种不同的硬件配置，作为使用者，很难对所有设备进行逐一性能测试，而采用标准的TPS性能系数，可以简化测试流程，使用者按照业务特点，进行测试获取到每个业务操作所需的TPS，最终将所有业务所需的TPS进行汇总得到所需机型的TPS值。

DBServer的TPS

＝每个操作的性能之合/冗余系数

＝(开户性能+销户性能+管理查询性能+设置性能+下载性能+数据同步性能)/冗余系数0.7

＝(开户数×每次开户操作性能值TPS+销户数×每次销户操作性能值TPS+管理查询性能值TPS×每次管理查询操作性能值TPS+设置数×每次设置操作性能值TPS+下载数×每次下载操作性能值TPS+呼叫节点DB Server数据同步TPS)/冗余系数0.7。

业务发展趋势分析和用户行为分析模块根据业务数据采集子系统收集到的业务运行信息，进行用户喜好分析和业务功能使用分析。

业务发展趋势分析和用户行为分析模块进一步包括用户喜好分析单元、业务功能使用分析单元、用户发展趋势单元和用户消费趋势单元。

用户喜好分析单元根据业务数据采集子系统收集到的用户下载、设置信息，找到用户的喜爱和偏好。

系统操作人员提前设置预制条件，例如提取每个用户下载最多的铃音种类、提取每个用户喜爱歌手名称、提取每个用户每月资费信息、提取每个用户最近的下载铃音种类等；用户喜好分析单元定期从彩铃数据库中同步用户相关信息；数据库返回操作结果给用户喜好分析单元；根据操作人员设置分析预制条件，筛选数据；将筛选数据存储到系统中，为以后数据检索做准备。

业务功能使用分析单元根据数据收集模块收集到的开销户数、铃音定购数和用户下载设置信息，分析当前系统业务使用情况，分析当前彩铃系统后台系统的负荷情况。

用户发展趋势单元分析用户发展趋势。

某时期内最大活动用户数＝MAX(每个统计点的活动用户数)；

某时期内活动用户的偏差率(提取用户开户的波动信息)＝AVEDEV(每个统计点的活动用户数)；

统计开户活跃的月份信息＝AVERAGEIF(每月开户数，＞＝平均开户数)；

统计销户活跃的月份信息＝AVERAGEIF(每月销户数，＞＝平均销户数)；

每月环比开户增长率＝(当月开户数-上月开户数)/上月开户数；

每月同比开户增长率＝(当月开户数-去年同月开户数)/去年同月开户数。

用户消费趋势单元分析用户消费趋势。

彩铃平台平均消费信息＝AVERAGE(彩铃平台每用户资费信息)；

每用户资费的偏差率＝AVEDEV(彩铃平台每用户资费信息)；

提取高于平均资费的活跃用户信息＝AVERAGEIF(彩铃平台每用户资费信息，＞＝平均资费信息)；

每月环比每用户资费增长率＝(当月每用户资费-上月每用户资费)/上月每用户资费；

每月同比每用户资费增长率＝(当月每用户资费-去年同月每用户资费)/去年同月每用户资费。

业务发展趋势分析和用户行为分析模块的价值主要体现在的业务数据挖掘方面，通过收集一手的用户使用信息，诸如用户资费信息，用户喜好，用户日常操作等信息，获取当前用户群的使用消费趋势，为后期的营销平台提供直观的素材，为后期精细化营销提供重要的数据参考。

业务故障数据分析模块根据业务数据采集子系统收集到的故障点数据信息，分析造成故障的原因，根据收集到的话务数据和业务使用量信息，分析故障点瞬时的业务波动信息，找到产生故障的网元信息。

业务故障数据分析模块进一步包括URP故障分析单元、呼叫控制部件故障分析单元和数据库及后台业务故障分析单元。

URP故障分析单元根据收集到的故障点话务数据，分析信令、资源各子部件的业务负荷量，结合当前系统可承载的业务量，进行数据对比，找出引起故障点的子系统。

呼叫控制部件故障分析单元根据收集到的故障点话务数据，分析当前系统CTI部件的信令处理负荷、活动呼叫数和呼叫处理时延信息，结合当前呼叫控制部件可承载的业务量，进行对比，评估呼叫控制部件是否为故障根源。

数据库及后台业务故障分析单元根据收集到的故障点后台业务使用信息，结合当前业务系统可承载的业务量，进行数据对比，找出产生故障的网元信息。

性能数据校验模块根据业务数据采集子系统采集的用户期望验证的性能模型数据，结合当前系统实际可承受的业务量，找出当前系统存在的瓶颈，作为扩容的依据。

性能数据校验模块进一步包括URP性能校验单元、呼叫控制部件性能校验单元和数据库及后台业务性能校验单元。

URP性能校验单元根据业务数据采集子系统传递的性能模型数据，分别验证信令和资源两个模块，如果当前系统无法承载所述性能模型，则所述URP性能校验单元提示用户具体存在瓶颈的子系统名称，并给出扩容意见。

呼叫控制部件性能校验单元根据业务数据采集子系统传递的性能模型数据，验证CTI系统是否可以承载所述性能模型，如果CTI系统无法承载所述性能模型，则所述呼叫控制部件性能校验单元给出扩容意见。

数据库及后台业务性能校验单元根据业务数据采集子系统传递的性能模型数据，验证整个彩铃后台系统是否可以承载所述性能模型，如果彩铃后台系统无法承载所述性能模型，则数据库及后台业务性能校验单元给出扩容意见。

数据显示子系统根据业务数据采集子系统收集的性能数据，结合性能分析子系统预设的性能原型，以数据表的形式展现系统各部件及子部件的负荷情况。

该数据显示子系统具有如下功能特点：动态的系统数据展示功能，使用者动态获悉各阶段运行数据；对于系统负荷超过70％的部件，进行预警提示；直观展现系统余量，方便使用者了解系统余量，针对重大节假日等特殊场景下，提前做好应急准备；直观展现系统瓶颈，聚焦运维关注点，了解今后扩容重点，有效节省设备投入。

最后应说明的是：以上所述仅为本发明的优选实施方式而已，并不用于限制本发明，尽管参照前述实施方式对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施方式所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (16)

1.一种彩铃系统性能评估的方法，其特征在于，包括以下步骤：

A、收集不少于两个时段的彩铃呼叫话务量Erl和对应时段内的平均放音时长，抽取其中数值最大的彩铃呼叫话务量Erl作为彩铃系统承载的最大话务量Erl；

B、将所述彩铃系统承载的最大话务量Erl与对应时段内的平均放音时长之商作为彩铃系统忙时并发呼叫数Caps；

C、采用以下公式获得内部通道数：

内部通道数＝彩铃系统忙时并发呼叫数Caps×所有时段的平均放音时长/(1-业务呼损率)；

D、采用以下公式获得信令链路数：

信令链路数＝Max(2，2×Roundup(彩铃系统忙时并发呼叫数Caps×呼叫消息数×每呼叫消息字节数×信令链路双向不均衡系数×8/(信令物理接口比特数×信令链路承载比例值)，0))，其中Roundup是向上取整函数，Max是取最大值函数。

2.根据权利要求1所述的一种彩铃系统性能评估的方法，其特征在于，所述业务呼损率是0.005。

3.根据权利要求1所述的一种彩铃系统性能评估的方法，其特征在于，所述呼叫消息数是5。

4.根据权利要求1所述的一种彩铃系统性能评估的方法，其特征在于，所述每呼叫消息字节数是30Byte。

5.根据权利要求1所述的一种彩铃系统性能评估的方法，其特征在于，所述信令链路双向不均衡系数是1.6。

6.根据权利要求1所述的一种彩铃系统性能评估的方法，其特征在于，所述信令物理接口比特数是64Kbit或者2Mbit。

7.根据权利要求6所述的一种彩铃系统性能评估的方法，其特征在 于，如果信令物理接口比特数是64Kbit，所述信令链路承载比例值是0.4，；如果信令物理接口比特数是2Mbit，所述信令链路承载比例值是0.2。

8.根据权利要求1所述的一种彩铃系统性能评估的方法，其特征在于，所述信令链路不少于2条。

9.一种彩铃系统性能评估的系统，其特征在于，包括业务数据采集子系统、性能分析子系统和数据显示子系统，其中，

业务数据采集子系统用于收集彩铃系统数据或者期待验证的性能数据；

性能分析子系统用于进行数据分析，并将输出结果导出给数据显示子系统；

数据显示子系统用于根据业务数据采集子系统收集的性能数据，结合性能分析子系统预设的性能原型，以数据表的形式展现系统各部件及子部件的负荷情况。

10.根据权利要求9所述的一种彩铃系统性能评估的系统，其特征在于，所述业务数据采集子系统进一步包括人工交互模块、系统主动收集模块、彩铃系统接口调用模块、接入设备收集筛选模块、呼叫设备收集筛选模块、后台服务器设备数据收集筛选模块和彩铃系统接口数据收集分配模块，其中：

人工交互模块用于采用Web界面，提供给用户手工录入，收集彩铃用户数、忙时试呼次数BHCA、放音时长、彩铃用户开销户数和月下载设置数；

系统主动收集模块用于收集彩铃系统日常的运行信息、并实现数据导入和数据库接口调用；

彩铃系统接口调用模块用于采用标准的简单对象访问协议SOAP接口，访问彩铃系统的语音增值业务开发平台USDP，收集语音增值业务开发平台USDP系统接口并发调用次数和语音增值业务开发平台USDP日志 信息；

接入设备收集筛选模块用于提取收集数据中，接入设备相关的信令数、中继数、忙时试呼次数BHCA和放音时长信息，提交给性能分析子系统；

呼叫设备收集筛选模块用于提取收集数据中，呼叫设备相关的忙时试呼次数BHCA和放音时长信息，提交给性能分析子系统；

后台服务器设备数据收集筛选模块用于提取收集数据中，彩铃后台业务语音增值业务开发平台USDP的相关信息，提交给性能分析子系统。

彩铃系统接口数据收集分配模块用于数据库接口调用，负责收集彩铃后台系统的运营信息，采用标准的JDBC接口调用，收集彩铃用户、彩铃用户开销户数和月下载设置数。

11.根据权利要求10所述的一种彩铃系统性能评估的系统，其特征在于，系统主动收集模块进一步包括数据导入单元和数据库接口调用单元，其中，

数据导入单元用于收集通用资源平台URP的话统数据；

数据库接口调用单元用于收集彩铃后台系统的运营信息，采用标准的JAVA数据库连接JDBC接口调用、收集彩铃用户、彩铃用户开销户数和月下载设置数。

12.根据权利要求9所述的一种彩铃系统性能评估的系统，其特征在于，所述性能分析子系统进一步包括性能逻辑分析模块、业务发展趋势分析和用户行为分析模块、业务故障数据分析模块和性能数据校验模块，其中，

性能逻辑分析模块用于对接入设备的性能进行分析；

业务发展趋势分析和用户行为分析模块用于根据业务数据采集子系统收集到的业务运行信息，进行用户喜好分析和业务功能使用分析；

业务故障数据分析模块用于根据业务数据采集子系统收集到的故障 点数据信息，分析造成故障的原因，用于根据收集到的话务数据和业务使用量信息，分析故障点瞬时的业务波动信息，找到产生故障的网元信息；

性能数据校验模块用于根据业务数据采集子系统采集的用户期望验证的性能模型数据，结合当前系统实际可承受的业务量，找出当前系统存在的瓶颈，作为扩容的依据。

13.根据权利要求12所述的一种彩铃系统性能评估的系统，其特征在于，所述性能逻辑分析模块进一步包括URP性能分析单元、呼叫控制部件性能分析单元和数据库性能分析单元，其中，

URP性能分析单元用于分析当前系统URP信令和媒体资源的负荷情况；

呼叫控制部件性能分析单元用于分析当前系统CTI部件的信令处理负荷、活动呼叫数和呼叫处理时延，并评估当前CTI系统的负荷情况；

数据库性能分析单元用于分析当前业务系统用户业务操作量、系统并发访问量和后台定时任务处理时长，并评估当前数据库的负荷情况。

14.根据权利要求12所述的一种彩铃系统性能评估的系统，其特征在于，所述业务发展趋势分析和用户行为分析模块进一步包括用户喜好分析单元、业务功能使用分析单元、用户发展趋势单元和用户消费趋势单元，其中，

用户喜好分析单元用于根据业务数据采集子系统收集到的用户下载、设置信息，找到用户的喜爱和偏好；

业务功能使用分析单元用于根据数据收集模块收集到的开销户数、铃音定购数和用户下载设置信息，分析当前系统业务使用情况，分析当前彩铃系统后台系统的负荷情况；

用户发展趋势单元用于分析用户发展趋势；

用户消费趋势单元用于分析用户消费趋势。

15.根据权利要求12所述的一种彩铃系统性能评估的系统，其特征 在于，所述业务故障数据分析模块进一步包括URP故障分析单元、呼叫控制部件故障分析单元和数据库及后台业务故障分析单元，其中，

URP故障分析单元用于根据收集到的故障点话务数据，分析信令、资源各子部件的业务负荷量，结合当前系统可承载的业务量，进行数据对比，找出引起故障点的子系统；

呼叫控制部件故障分析单元用于根据收集到的故障点话务数据，分析当前系统CTI部件的信令处理负荷、活动呼叫数和呼叫处理时延信息，结合当前呼叫控制部件可承载的业务量，进行对比，评估呼叫控制部件是否为故障根源；

数据库及后台业务故障分析单元用于根据收集到的故障点后台业务使用信息，结合当前业务系统可承载的业务量，进行数据对比，找出产生故障的网元信息。

16.根据权利要求12所述的一种彩铃系统性能评估的系统，其特征在于，所述性能数据校验模块进一步包括URP性能校验单元、呼叫控制部件性能校验单元和数据库及后台业务性能校验单元，其中，

URP性能校验单元用于根据业务数据采集子系统传递的性能模型数据，分别验证信令和资源两个模块，如果当前系统无法承载所述性能模型，则所述URP性能校验单元提示用户具体存在瓶颈的子系统名称，并给出扩容意见；

呼叫控制部件性能校验单元用于根据业务数据采集子系统传递的性能模型数据，验证CTI系统是否可以承载所述性能模型，如果CTI系统无法承载所述性能模型，则所述呼叫控制部件性能校验单元给出扩容意见；

数据库及后台业务性能校验单元用于根据业务数据采集子系统传递的性能模型数据，验证整个彩铃后台系统是否可以承载所述性能模型，如果彩铃后台系统无法承载所述性能模型，则数据库及后台业务性能校验单元给出扩容意见。 

Images