一种分析移动通信系统中呼叫的系统及方法

摘要

本发明公开了一种分析移动通信系统中呼叫的系统，包括：网元，用于采集呼叫日志信息，将满足该网元与管辖该网元的CHR Server预先约定的过滤条件的呼叫日志信息上报给所述CHR Server；CHR Server，用于收集、存储各网元上报的呼叫日志信息，以及根据呼叫日志信息对其监控下的呼叫进行分析，以及将呼叫日志信息上报给NMS；NMS，用于收集其管辖内CHRServer的呼叫日志信息，以及对其监控下的呼叫进行分析。本发明还提供了一种分析移动通信系统中呼叫的方法。本发明可以分析已发生的呼叫，从而定位已发生呼叫中的故障和异常。本发明还具有成本低、数据量小、自动监测分析呼叫信息等优点。

说明书

技术领域

本发明涉及通信系统中操作与维护技术领域，特别是分析移动通信系统中呼叫的系统及方法。

背景技术

移动通信网络是通信网络中最复杂的一种通信系统，移动用户的移动性带来了很多关于漫游、切换、覆盖的问题，如果不能及时分析定位移动通信中呼叫、解决移动用户遇到的问题，将会降低通话的质量，从而给运营商的客户满意度、声誉带来很大的影响。

在移动通信网中，用来定位呼叫故障和网络故障的现有技术主要有：集中信令监测、用户跟踪等技术。

现有技术一：集中信令监测方案

信令集中监测系统通过高阻跨接方式从承载业务网络的信令链路采集信令数据，并进行分析和统计，可全面反映出业务网络的运行状况，为网络的维护、优化和扩容，以及运营商网间的互联互通质量监督提供依据，并可为规划业务、制订经营战略提供基础信息。

但是，集中信令监测方案具有如下缺点：信令监测要提取每条链路的每一条信息，因此具有海量的信息，而信令监测系统很难及时处理海量的数据；要在所有信令链路上挂接监测仪表，增加了信令监测的成本，如果在3G系统中使用该方法，成本将会更高；信令监测只能提取标准接口上的标准信元，而系统内部的信息一无所知，从而无法分析系统内部的细节信息，难以关联同一呼叫中的所有会话。

现有技术二：跟踪(Trace)用户跟踪方案

用户和移动台Trace是在操作与维护中心(Operation & MaitenanceCenter，OMC)上实现的一种功能。它在呼叫层次上提供对一个或多个指定移动台进行详细信令跟踪的应用，这些数据是性能管理数据的额外补充，可用来对网络进一步的监视和优化。跟踪由用户命令激活，并以在有限时间内实现特定分析为目的。

但是，Trace方案具有如下缺点：监测的用户数量有限，一般只能同时监测几十个用户；无法自动开启监测，需要手动打开监测；不能记录用户的历史呼叫信息，只能监测可以重现的网络故障，即不具有回溯功能。

发明内容

有鉴于此，本发明提出了一种分析移动通信系统中呼叫的系统及方法，其目的在于，能够分析已发生的呼叫。本发明的进一步目的在于，定位已发生呼叫中的故障和异常，以及降低分析定位呼叫的成本，控制所需呼叫信息的数据量以及能够自动实现监测。

根据上述目的，本发明提供了一种分析移动通信系统中呼叫的系统，该系统包括：网元，用于采集呼叫日志信息，将满足该网元与管辖该网元的呼叫历史纪录服务器(CHR Server)预先约定的过滤条件的呼叫日志信息上报给所述CHR Server；CHR Server，用于收集、存储各网元上报的呼叫日志信息，以及根据呼叫日志信息对其监控下的呼叫进行分析，以及将呼叫日志信息上报给网络管理系统(NMS)；NMS，用于收集其管辖内CHR Server的呼叫日志信息，以及对其监控下的呼叫进行分析。

所述网元包括：功能单板模块，用于采集呼叫日志信息，并将所采集的呼叫日志信息直接上报给管辖所述网元的CHR Server。

另外，所述网元包括：功能单板模块，用于采集呼叫日志信息，并将所采集的呼叫日志信息发送给呼叫历史纪录代理(CHR Agent)；CHR Agent，用于将所述呼叫日志信息上报给管辖该网元的CHR Server。

在上述方案中，所述网元为移动交换中心服务器、媒体网关、支撑通用分组无线业务节点、网关通用分组无线业务节点、无线网络控制器或归属位置寄存器以及宽带码分多址移动通信系统中任意的其它网元。

所述CHR Server包括：CHR Server模块，用于接收来自网元的呼叫日志信息，并将所述呼叫日志信息存储到呼叫日志记录数据库(CHR DB)、发送给呼叫日志信息客户端(CHR Client)以及发送给NMS；CHR DB，用于存储呼叫日志信息；CHR Client，用于根据呼叫日志信息对该CHR Server监控下的呼叫进行后处理分析。

较佳地，该系统进一步包括：备用CHR Server，用于利用心跳线监测所述CHR Server的工作状态，当监测到所述CHR Server发生异常时，代替所述CHR Server工作。

在上述技术方案中，所述CHR Server进一步用于向任意第三方工具提供呼叫日志信息。

所述网元与CHR Server预先约定的过滤条件为：上报所有的呼叫日志信息、上报指定小区内的所有呼叫日志信息、上报指定呼叫失败原因的呼叫日志信息、上报指定用户的所有呼叫日志信息、上报指定时间段内的所有呼叫日志信息、上报故障呼叫的呼叫日志信息、上报异常呼叫的呼叫日志信息、上报指定用户的标准信令接口的呼叫日志信息、上报预定详细等级的呼叫日志信息、上报呼叫日志记录中任何一个信息或者它们之中的任意组合。

当所述CHR Server为设备管理系统EMS的一部分时，所述网元通过该网元与EMS之间的网管通道上报呼叫日志信息。

所述CHR Server进一步用于定位所分析的呼叫的故障和异常；和/或所述NMS进一步用于定位所分析的呼叫的故障和异常。

所述CHR Client进一步用于定位所分析的呼叫的故障和异常。

本发明还提供了一种分析移动通信系统中呼叫的方法，该方法包括：A.网元采集呼叫日志信息，并将满足该网元与管辖该网元的呼叫历史纪录服务器CHR Server预先约定的过滤条件的呼叫日志信息上报给所述CHRServer；B.CHR Server根据所接收的呼叫日志信息，对其监控下的呼叫进行分析，以及将所述呼叫日志信息上报给NMS；C.NMS根据所接收的呼叫日志信息，对其监控下的呼叫进行分析。

该方法进一步包括：CHR Server将所述过滤条件下发给所管辖的网元；和/或NMS将所述过滤条件下发给所管辖的CHR Server。

所述CHR Server进一步定位所分析的呼叫的故障和异常；和/或所述NMS进一步定位所分析的呼叫的故障和异常。

从上述方案中可以看出，由于本发明利用网元采集并上报呼叫日志信息，CHR Server和NMS根据所上报的呼叫日志信息分析呼叫，从而能够分析已发生的呼叫，进一步可以定位已发生呼叫中的故障和异常。并且本发明的各组成部分可以集成在现有设备内部，不需另外的设备采集信令链路信息，可以自动实现全小区全天候的跟踪记录。本发明记录的信息量少，仅是原始编码消息解码处理后的信息摘要，还可以进一步根据运营商定制信息。并且与现有技术相比，本发明的监测成本比较低，另外可以借用现有设备本身的呼叫处理流程进行分析，比另建立一套分析逻辑的成本要低。本发明可以采集呼叫过程中的任何信息，包括非标准接口、内部信息。本发明可以降低后台分析工具的复杂度，后台分析工具可以很容易找出同一呼叫的关联消息并迅速定位故障和异常。总之，本发明在网络故障分析、性能分析、客户投诉处理、用户行为分析等多个领域有着广泛的应用。

附图说明

图1为根据本发明的系统的架构图；

图2为本发明所提供实施例中的网元的内部结构示意图；

图3为本发明所提供实施例中的设备管理层的结构示意图；

图4为本发明所提供实施例中的网络管理层的结构示意图；

图5为本发明所提供实施例中的指定过滤条件的示意图。

进一步详细说明。

本文提供的是一种在移动通信系统内部实现、用于分析移动通信系统中的呼叫并可进一步定位移动通信系统中呼叫异常和故障的技术方案，该方案通过记录和分析移动通信网中呼叫的运行轨迹和状态参数，精确无误定位出呼叫失败的原因，并迅速解决用户遇到的问题。

参考图1，本发明所提供的系统可以分为三个层面：网元(networkelement，NE)层、设备管理(equipment management)层和网络管理(networkmanagement)层。

网元层包括网元，网元负责采集呼叫日志信息，以及根据网元与管辖该网元的呼叫历史纪录服务器(Call History Record Server，CHR Server)预先约定的过滤条件，将满足该过滤条件的呼叫日志信息上报给管辖它的CHRServer。这里所述的过滤条件表示应用于不同的场景，具体内容将在后面进行描述。

如图1所示，网元可以是移动交换中心服务器(Mobile Switching CenterServer，MSC Server)、媒体网关(Media Gateway，MGW)、支撑通用分组无线业务节点(Support GPRS Service Node，SGSN)、网关通用分组无线业务节点(Gateway GPRS Service Node，GGSN)、无线网络控制器(RadioNetwork Controller，RNC)或者归属位置寄存器(Home Location Register，HLR)等等宽带码分多址(WCDMA)移动通信系统中的任何网元。

图2为网元的内部结构示意图。参照图2，网元的内部包括功能单板模块(Function Board)和呼叫历史纪录代理(CHR Agent)。Function Board负责采集呼叫日志信息，并根据该网元与管辖该网元的CHR Server预先约定的过滤条件，将满足该过滤条件的呼叫日志信息发送给CHR Agent，由CHR Agent上报给管辖该网元的CHR Server。CHR Agent对接收到的呼叫日志信息缓存后，再通过标准的接口或者内部接口将呼叫日志信息上报给CHRServer。当然，也可以把CHR Agent内嵌到Function Board中，即FunctionBoard采集呼叫日志信息后，直接将满足过滤条件的呼叫日志信息发送给CHR Server。

由于CHR Server与设备管理系统(EMS)在同一层面，CHR Server可以作为EMS逻辑上的一部分，因此可以利用EMS与网元之间现有的网管通道从网元上报呼叫日志信息。当然，网元也可以使用新的物理链路与CHRServer建立连接，上报呼叫日志信息。

接着描述设备管理层。设备管理层包括CHR Server。CHR Server收集存储所管辖的网元上报的呼叫日志信息，根据呼叫日志信息对其监控下的呼叫进行分析，从而定位呼叫中的故障和异常，CHR Server还可以将呼叫日志信息上报给NMS。

参照图3，CHR Server包括CHR Server模块、呼叫历史记录数据库(CHRDB)和呼叫历史记录客户端(CHR Client)。其中，CHR Server模块接收来自网元的呼叫日志信息，将这些呼叫日志信息存储到CHR DB，以及发送给CHR Client，并且CHR Server模块还可以将呼叫日志信息上报给NMS。CHR DB用于存储呼叫日志信息，还可以进一步向第三方工具提供呼叫日志信息，以便第三方工具进行其它分析。CHR Client根据CHR Server模块发送来的呼叫日志信息，对CHR Server监控下的呼叫进行分析。

考虑到CHR Server的冗余备份，可以设置主备CHR Server。如图1所示，图1中两个CHR Server都接收来自网元的呼叫日志信息，但是只有一个CHR Server处于工作状态，另一个CHR Server通过之间的心跳线监测对方的工作状态，当发现对方发生异常时，立即取代对方进入工作状态。在这种情况下，图3中的CHR Server模块就进一步通过心跳线与互为备份的CHRServer的CHR Server模块相连接，并监测对方的工作状态，当发现对方发生异常时，立即取代对方进入工作状态。

接下来，描述网络管理层。参照图4，网络管理层的网络管理系统(NMS)与其管辖的CHR Server相连接，收集其管辖内CHR Server上报的呼叫日志信息，并且可以对其监控下的呼叫进行分析，从而定位呼叫中的故障和异常。

下面描述网元上报呼叫日志信息的场景，相当于前面所述的网元上报呼叫日志信息的过滤条件。如图5所示，这些过滤条件可以预先从CHR Server下发给网元，而且CHR Server也可以预先通过北向接口或其它接口从NMS下发的条件输出命令，即过滤条件。

情形1：过滤条件为上报所有的呼叫日志信息。网元记录所有的呼叫日志信息，按照与CHR Server之间的接口规则，将所有呼叫日志信息上报给CHR Server，用于全网的分析和故障定位。

情形2：过滤条件为上报指定小区、局向、中继等的所有用户的呼叫日志信息。以指定小区为例说明，网元将指定小区内的所有呼叫日志信息上报给CHR Server，从而可以用于基于小区的各种呼叫分析。

情形3：过滤条件为上报指定故障原因值的所有用户的呼叫日志信息。例如，网元将指定呼叫失败原因的故障呼叫的呼叫日志信息上报给CHRServer，从而可以用于对该故障呼叫的分析、定位。

情形4：过滤条件为上报指定用户的呼叫日志信息。例如，在CHR Server上可以指定某些用户的跟踪，网元将这些用户的所有呼叫日志信息全部上报给CHR Server，从而可以对这些指定的用户的呼叫进行分析。

情形5：过滤条件为上报指定时间段内的所有呼叫日志信息。例如，在CHR Client上可以指定某一段时间，网元将该时间段内的所有呼叫信息上报，从而可以用于进行和时间相关的性能、故障分析。

情形6：过滤条件为上报故障类呼叫的呼叫日志信息。为了降低对网络设备性能的影响，可以仅将故障、异常呼叫的呼叫日志信息上报给CHRServer。例如，网元默认监测所有的呼叫，当呼叫发生的错误与期望上报的错误一样时，网元即上报该故障呼叫的呼叫日志信息。所述错误可以是话音单通、通话中掉话等等。

情形7：过滤条件为上报制定用户标准信令接口的呼叫日志信息。例如，在CHR Client上可以指定少量用户的全信令跟踪，网元将这些用户的所有信令接口消息全部上传给CHR server，从而可以对用户进行更为细致的分析。该情形主要用在网络互联互通、终端与网络配合监测上等情况。

过滤条件还可以进一步为上报呼叫日志记录中任何一个信息。

另外，由于指定用户标准接口的消息包含了协议各层的消息，消息量通常很大。为了降低信息量，可以对协议层的消息进行等级划分，在进行指定用户标准接口跟踪的时候，只需要上报指定等级的消息。例如，根据消息的详细程度将消息分为3类：最大详细级别、最小详细级别、中度详细级别。其中最大详细级别包括信令接口的原始编码消息；最小详细级别为最大详细级别的子集，是指原始编码消息解码后从中抽取能够进行一般问题定位所需的消息集合；中度详细级别为最大详细级别的子集，是指原始编码消息解码后，从中抽取能够进行较深问题定位所需的消息集合，中度详细级别介于最大详细级别和最小详细级别之间。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。