br>[0037] 在本发明实施例中，根据上述统计数据对上述系统容量进行预测分析，包括：对上 述统计数据建立巡检项目；通过执行上述巡检项目生成对上述系统容量分析的结果。
[0038] 统计数据W表格或excel附件的形式存在，每张表对应一个巡检项，话务模型类 巡检项有一张表和一个excel附件，而容量分析类巡检项有两张表和一个excel附件。话 务模型类巡检项的表包含多个话务类指标的数据，附件包含指标最基本的数据。容量分析 类巡检项的表包含容量类指标的数据，一个包含指标口限告警数据，另一个包含指标的统 计数据，附件包含指标最基本的数据。
[0039] 在建立了巡检项目之后，本发明优选实施例还提供了一种按照巡检项分析统计数 据的过程，如下所示：
[0040] W下W上述统计数据中的最底层数据为例：
[0041] IX语音话务模型。包括IX:全局语音呼叫请求次数、IX:全局语音呼叫话务量 巧rl)、IX:全局语音平均通话时长（S)等指标。送些指标反映了现网IX语音话务的基本情 况。例如，2014-03-1010:00:00的IX:全局语音呼叫请求次数=384562,说明该局10时语 音呼叫总次数为384562次。
[0042] IX短消息话务模型。包括IX:全局短消息呼叫话务量巧rl)、1X:全局短消息平 均通话时长（S)UX:全局短消息呼叫请求次数度HCA)等指标。送些指标反映了现网IX短 消息话务的基本情况。例如，2014-03-1010:00:00的IX:全局短消息呼叫请求次数度HCA) =145076,说明该局10时短消息呼叫总次数为145076次。
[0043] IX数据话务模型。包括IX:全局数据呼叫请求次数、IX:全局数据呼叫话务量 巧rl)、lX:全局数据每呼叫平均流量（邸）等指标。例如，2014-03-1010:00:00的IX:全 局数据每呼叫平均流量（KB) = 191. 67,说明该局10时数据每次呼叫所占用的平均流量为 191. 67千字节。
[0044] PTT话务模型。包括PTT:全局传统组呼平均群组呼叫时长（s)、PTT:全局 传统组呼平均群组占用小区数目、PTT:全局传统组呼话务量巧rl)等指标。例如， 2014-03-1010:00:00的PTT:全局传统组呼话务量巧rl) = 0,说明该局没有PTT业务。 [004引 DO话务模型。包括DO:全局无线网络连接请求次数（含A8、A10接口）、D0:全局 每连接平均流量（邸）、D0:全局RLP平均吞吐量化bps)等指标。例如，2014-03-1010:00:00 的DO:全局RLP平均吞吐量化bps) = 114. 82,说明该局10时RLP平均吞吐量为114. 82千 位每砂。
[0046] W下简单W上述统计数据中的中间层为例：
[0047] B肥A容量分析；除了 MP板、PP板、CC板的利用率数据外，还有BCM5615、BCM56XXX 框间控制流数据，W及接入信道、控制信道、寻呼信道的利用率。例如，2014-03-1010:00:00 的UIM CPU最高利用率（％)出现口限告警，说明有UIM单板在10时的最高利用率超过口 限，处于较高负荷的工作状态，如果UIM单板最高利用率在较长时间内多次处于高负荷状 态，且UIM单板过载率较高（过载UIM单板数除W总UIM单板数），则说明UIM单板已不能 安全稳定的工作，需要增加 UIM单板或者采取其他改进措施，W满足不断增大的网络容量 需求。UIM单板属于PP单板，如果仅从UIM单板角度，判定当前网络是否正常工作，显然是 不具说服力的，为此，还有PP板过载率、MP板过载率、CC板过载率等全局性统计数据（最高 层数据）。除各种单板统计数据外，还有框间控制流，信道利用率等统计数据。用户结合送 3层数据不难估量出当前网络运行状况。
[0048] W下简单W上述统计数据中的最高层为例：
[0049] 话务量容量分析。本巡检项中的统计数据主要描述系统资源的使用情况，包含IX: 全局无线资源过载率（％)、IX:全局前向CE过载率（％)、IX:全局反向CE过载率（％)、 IX:前向发射功率过载率（％)、DO:全局前向物理层业务信道过载率（％)、DO:全局反 向链路过载率（％ ) W及DO:全局前向业务MacIndex过载率（％ )等统计数据。例如， 2014-03-1010:00:00的IX:全局前向CE过载率（％)= 1. 15,说明10时基站的前向信道 的过载率为百分之1. 15。
[0050] 吞吐量容量分析。包括PUB:全局IPCF端口过载率（％ )、PUB:全局AbiS 口带宽 过载率（％ )、PUB:全局UPCF单板过载率（％)等统计数据。例如，2014-03-1010:00:00的 PUB:全局IPCF端口过载率（％)= 0,说明10时没有过载的IPCF端口。
[0051] 上述实施例提供的技术方案可W理解是对现网巡检项统计数据的分为H层后的 分析过程，而对于预测过程的巡检项的统计数据的分析过程大致过程和上述过程相同，但 还需说明一下几点：
[0052] 1、预测指标的过载口限和现网性能指标相同，而采用送样的技术方案使得统计出 来的过载率才能体现预测容量和现网容量的变化和区别。
[0053] 2、预测指标的统计数据一般大于等于对应的现网统计数据，因为预测指标算法等 效于现网指标算法乘W某个大于1的增长比值（相当于上述实施例的预定值）得来，故预 测指标的数据和统计数据不会小于现网的数据。
[0054] 3、容量预测分析主要针对BHCA容量分析、话务量容量分析、吞吐量容量分析送3 个巡检项统计出来的数据，因为上述参数能够直接反映网络设备使用情况。本发明实施例 上述提供3层统计数据供用户参考分析，进而了解网络现网运行状况和网络未来运行状 况。
[00巧]综上所述，本发明实施例按不同网元级别、不同层次统计现网指标（反映当前网 络状态）和预测指标（反映未来网络状态），并生成统计数据报告，用户可据此了解现网状 态和网络未来大致运行状态。
[0056] 为了更好的理解上述系统容量的预测过程，W下结合优选实施例进行说明：
[0057] 图2为根据本发明优选实施例的预测模块数据处理W及通信的流程图，如图2所 示，图2中的用户输入模块30与数据汇总及显示模块34可W理解为是一种巡检工具、中间 层可W理解为是操作维护中必的peration Maintenance Centre,简称为0MC)、数据查询及 预处理模块32可W理解为CN02。
[0058] 图2中，用户输入模块30、数据汇总及显示模块34都集成在巡检工具上，W容量预 测场景的形式存在。数据查询及预处理模块32集成在CN02上，由于巡检工具只与OMC (中 间层）通信，而OMC能与CN02通信，所W，实施例中的OMC只起转发消息和文件的作用。如 果巡检工具能与CN02直接通信，OMC送个中间层是可W省略的。
[0059] W下详细说明巡检工具和CN02在本发明实施例中如何实现图3中模块功能的：
[0060] 1)巡检工具中的基本元素是巡检项，巡检项包含多个指标（大多与CN02中性能指 标对应）、用户参数信息（如指标口限、指标值、巡检时间等），实现了各种供框架调用的接 口，当巡检项执行时，框架将调用送些接口。
[0061] 巡检工具中有默认场景，场景包含多个巡检项，用户可W自定义场景。容量预测场 景包含16个巡检项，可分为W下4种类型。
[0062] 现网话务模型；IX语音话务模型、IX短消息话务模型、IX数据话务模型、PTT话务 模型、DO话务模型。
[0063] 现网容量分析；BHCA容量分析、话务量容量分析、吞吐量容量分析。
[0064] 预测话务模型；IX语音话务模型（预测）、IX短消息话务模型（预测）、IX数据话 务模型（预测）、PTT话务模型（预测）、DO话务模型（预测）。
[0065] 预测容量分析；BHCA容量分析（预测）、话务量容量分析（预测）、吞吐量容量分 析（预测）。
[0066] 如下所示；W上四种类型的巡检项向上依赖，即预测容量分析依赖预测话务模型， 预测话务模型依赖现网容量分析和现网话务模型，现网容量分析依赖现网话务模型。所W， 在执行容量预测场景时，巡检项的执行顺序必须遵守表一中的依赖关系，例如：如果巡检项 A依赖B和C，若要执行A，则必须首先成功执行B和C，否则A不能执行。
[0067] 〈predict dependency〉
[006引 〈indicatoritem id 二"11000009" desc 二"BHCA 容量分析"〉
[0069] <(16口6〇化古61111(1二，，11000012，，(163〇二，，1又语音话务模块，，/〉
[0070] <dependitem id 二"11000013" desc 二"IX 短消息话务模型"/〉
[0071] <d邱enditem id 二"11000014" desc 二"IX 数据话务模型"/〉
[0072] <d邱enditem id 二"11000015" desc 二"PTT 话务模型"/〉
[007引 <d邱enditem id 二" 11000016，，desc 二"DO 话务模块，，/〉
[0074] </indicatoritem>