CN101150858A - 呼叫异常分析方法及装置、呼叫异常预防方法及装置 - Google Patents

Abstract

本发明实施例中公开了一种进行呼叫异常分析的方法，该方法首先根据呼叫历史记录(CHR)数据确定呼叫异常发生时用户所在的小区；然后，对所述小区所属基站的接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。本发明实施例中还公开了一种呼叫异常分析装置、两种预防呼叫异常的方法以及两种呼叫异常预防装置。应用本发明能够提高呼叫异常分析的分析效率，对大规模爆发呼叫异常进行预防。

Description

呼叫异常分析方法及装置、呼叫异常预防方法及装置

技术领域

本发明涉及无线通信中的呼叫处理技术，特别涉及进行呼叫异常分析的方法、呼叫异常分析装置、预防呼叫异常的方法及呼叫异常预防装置。

背景技术

移动网络的用户在使用移动服务的过程中，遇到掉话或者接入失败等异常情况时，将向运营商投诉。为了提高服务质量，运营商总是要在第一时间响应用户的投诉，将出现异常的原因告诉用户，并根据所述原因解决网络中所存在的问题，避免再次出现异常。现有技术中存在一种基于呼叫历史记录(CHR)进行呼叫异常分析的技术方案，大致包括以下步骤：

第1步：记录投诉用户的终端号码、投诉用户所提供的异常发生时间、异常发生地点等信息。

第2步：分析CHR数据。

CHR数据中包含有呼叫异常信息，例如：发生呼叫异常的国际移动用户标识(IMSI)、异常发生时间、异常发生时用户所在小区、呼叫异常的打点信息等。

呼叫流程中可能会经历的过程、事件等，被定义成在时间上具有一定先后次序的点。在处理呼叫的过程中，每经历一个过程或事件，系统就会记录相应的点(也就是通常所说的打点)以及相关的上下文信息。若呼叫异常结束，则将IMSI、异常发生时间、异常发生时用户所在的小区、相应的打点信息等作为呼叫异常信息记录在CHR数据中。

本步骤中，可以根据投诉用户的终端号码，确定与该终端号码相应的IMSI，并在CHR数据中找到与该IMSI相应的呼叫异常信息，然后根据异常发生时间附近的打点信息分析呼叫异常的原因。

第3步：若通过上述第2步没能定位出呼叫异常的原因，则安排相关人员根据异常发生的位置进行路测，复现问题，并启动信令跟踪，找到呼叫异常发生的原因。

本申请的发明人在实现本发明的过程中发现，上述现有技术方案存在如下缺陷：

1、上述现有技术方案只能定位出由无线网络方面的原因所导致的呼叫异常，但是，当导致呼叫异常的原因是由于网络中的设备发生故障时，上述技术方案无法定位出真正的问题。例如：当由于设备的传输不通或设备闪断，导致出现空口信号不好、接入成功率低等情况时，上述技术方案无法根据CHR定位异常原因，此时，将耗费大量的人力、物力进行路测，以期定位问题。但是，最后定位的结果发现不是无线网络的问题，而是设备的问题，这一方面需要耗费大量的人力、物力，另一方面使得用户的投诉不能得到及时的响应，导致分析效率较低。

2、进行路测时所启动的信令跟踪将产生大量数据，对这些数据的分析复杂且耗时，并且，其中大部分数据都是无用的，这也使得分析效率较低。

3、由于是事后分析，导致用户呼叫异常的原因可能已经自动恢复，从而使得路测时不可或者难于复现所述呼叫异常，继而无法定位出导致呼叫异常的真正原因。

4、上述技术方案是根据用户的投诉进行的被动分析，当网络中存在导致呼叫异常的隐患时，不能对所述隐患进行主动预防，从而可能导致异常的大量爆发，影响客户满意度。

发明内容

本发明实施例提供一种进行呼叫异常分析的方法和呼叫异常分析装置，以提高呼叫异常分析的分析效率。

本发明实施例还提供一种预防呼叫异常的方法和呼叫异常预防装置，以对大规模爆发呼叫异常进行预防。

本发明实施例还提供另一种预防呼叫异常的方法和呼叫异常预防装置，以对大规模爆发呼叫异常进行预防。

为达到上述目的，本发明实施例的技术方案具体是这样实现的：

一种进行呼叫异常分析的方法，包括：

根据呼叫历史记录CHR数据确定呼叫异常发生时用户所在的小区；

对所述小区所属基站的接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

一种呼叫异常分析装置，包括：

CHR数据分析模块，用于根据CHR数据确定呼叫异常发生时用户所在的小区；

异常定位模块，用于对所述小区所属基站的接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

一种预防呼叫异常的方法，包括：

对指定时间段内的CHR数据进行统计分析，确定发生呼叫异常最多的N个小区，所述N为大于等于1的整数；

对所述N个小区所属基站的接口配置对象在所述指定时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

一种呼叫异常预防装置，包括：

CHR数据分析模块，用于对指定时间段内的CHR数据进行统计分析，确定发生呼叫异常最多的N个小区，所述N为大于等于1的整数；

异常定位模块，用于对所述N个小区所属基站的接口配置对象在所述指定时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

一种预防呼叫异常的方法，包括：

对指定时间段内的告警数据进行统计分析，确定产生告警最多的N个接口配置对象，并确定所述N个接口配置对象对应的基站，所述N为大于等于1的整数；

对所述基站对应的小区在所述指定时间段内的CHR数据进行分析，确定所述告警对所述呼叫异常的影响，定位呼叫异常的原因。

一种呼叫异常预防装置，包括：

告警数据分析模块，用于对指定时间段内的告警数据进行统计分析，确定产生告警最多的N个接口配置对象，并用于确定所述N个接口配置对象对应的基站，所述N为大于等于1的整数；

异常定位模块，用于对所述基站对应的小区在所述指定时间段内的CHR数据进行分析，确定所述告警对所述呼叫异常的影响，定位呼叫异常的原因。

由上述技术方案可见，本发明实施例提供的进行呼叫异常分析的技术方案，首先根据CHR数据确定呼叫异常发生时用户所在的小区，然后根据所述小区所属基站的传输配置数据确定该小区所属基站的接口配置对象，最后，对所述接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警数据进行告警分析，从而通过判断告警对呼叫异常的影响，定位出呼叫异常的原因。可见，本发明实施例所提供的技术方案通过传输配置数据建立起CHR数据与告警数据之间的关联，进而利用CHR数据与告警数据之间的时间关联性，判断设备告警对呼叫异常所产生的影响，定位出设备故障方面的呼叫异常原因。如此，不必在根据CHR数据无法定位呼叫异常的原因时就直接进行路测、信令跟踪等，从而能够以最小的代价定位出呼叫异常的原因，使得呼叫异常分析的分析效率得到了极大的提高。

本发明实施例所提供的预防呼叫异常的技术方案，也是通过传输配置数据建立起CHR数据与告警数据之间的关联，进而利用CHR数据与告警数据之间的时间关联性，通过统计分析指定时间段内发生呼叫异常最多的N个小区或告警最多的N个接口配置对象来达到主动发现问题，主动消除问题的目的，从而实现对呼叫异常的主动预防，预防大规模呼叫异常的爆发。

附图说明

图1为本发明实施例中进行呼叫异常分析的方法的流程示意图；

图2为本发明实施例中呼叫异常分析装置的组成结构示意图。

具体实施方式

为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明作进一步详细说明。

引起呼叫异常的原因大致可以分为两种：无线网络方面的原因和设备方面的原因。如前所述，CHR数据中将记录有呼叫异常信息，CHR数据能够体现无线网络方面的原因所导致的呼叫异常，为呼叫异常分析提供相关的分析依据；而与设备故障或链路故障相关的信息则记录在告警数据中。

对于已知的呼叫异常(例如：用户的投诉)，本发明实施例提供的技术方案是：在利用CHR数据无法定位呼叫异常的原因时，通过CHR数据确定呼叫异常发生时用户所在的小区；再通过该小区所属基站的传输配置数据确定该小区所属基站配置了哪些接口配置对象，也就是配置了哪些设备；最后，根据这些设备的告警数据进行告警分析，如果这些设备在呼叫异常发生时或在呼叫异常发生时的相邻时间段内产生过告警，则进一步判断所述告警对应的故障是否是导致所述呼叫异常的原因，从而对呼叫异常的原因进行定位。这里，“呼叫异常发生时的相邻时间段内”包括：呼叫异常发生之前的一段时间和/或呼叫异常发生之后的一段时间，所述一段时间的长度可以预先设置，也可以根据实际应用的需要动态进行设置。

对于希望对呼叫异常的大规模爆发进行主动预防的应用场景，本发明实施例提供了两种技术方案。这两种技术方案都是通过传输配置数据建立起CHR数据与告警数据之间的关联，进而利用CHR数据与告警数据之间的时间关联性，来达到主动发现问题、主动消除问题的目的，从而实现对呼叫异常的主动预防。具体而言：

第一种技术方案是：首先，对指定时间段内的CHR数据进行统计分析，确定发生呼叫异常最多的N个小区，所述N为大于等于1的整数；

然后，对所述小区所属基站的接口配置对象在所述指定时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

第二种技术方案是：首先，对指定时间段内的告警数据进行统计分析，确定产生告警最多的N个接口配置对象，并确定所述N个接口配置对象对应的基站，所述N为大于等于1的整数；

然后，对所述基站对应的小区在所述指定时间段内的CHR数据进行分析，确定所述告警对所述呼叫异常的影响，定位呼叫异常的原因。

上述两种技术方案从本质上来说是一样的，区别仅在于先分析CHR数据还是先分析告警数据。

下面对本发明实施例所提供的上述技术方案的具体实施方式进行详细说明。

图1为本发明实施例中进行呼叫异常分析的方法的流程示意图。参见图1，以收到一个用户投诉为例进行说明，该方法包括：

步骤101：记录投诉用户的终端号码、投诉用户所提供的异常产生时间、异常发生地点等信息。

步骤102：分析CHR数据。

本步骤与背景技术所述分析CHR数据的操作相同：根据投诉用户的终端号码，确定与该终端号码相应的IMSI，并在CHR数据中分析与该IMSI相应的呼叫异常信息，包括：分析异常发生的时间、异常发生时用户所在小区，进而可以确认用户投诉的准确性，并根据异常发生时间附近的打点信息分析呼叫异常的原因。

如果通过本步骤的分析，没能定位出呼叫异常的原因，则可以继续执行步骤103，按照本发明实施例所提供的方法继续进行呼叫异常分析。

步骤103：确定异常发生时用户所在的小区，获取所述小区所属基站与基站控制器之间的传输配置接口的传输配置数据。

CHR数据的数据结构比较复杂，以下示出所述CHR数据结构中与本实施例相关的单用户日志子结构：

{

 UINT8                enProcedure；//过程名

 UINT8                enRrcState；//rrc连接状态

 UINT8                ucRabNum；//Rab个数0..3

 //业务类型

 UINT8                aenTraffic[RNC_MAX_RAB_PER_UE]；

 //CN域类型

 UINT8                aenDomain[RNC_MAX_RAB_PER_UE]；

 UINT8                ucActSetNum；//活动集个数0.3

 UINT32               aulCellId[RNC_MAX_RL_PER_UE]；//小区ID

 UINT8                ucNodeBNum；//Nodeb数目

 UINT8                ucDrncNum；//Drnc数目

 UINT8                enCMState；//为压缩模式状态

 UINT8                ucRsvd；//DSP需要四字节对齐

}DBG_AGENT_USER_STATE；

其中，UINT32aulCellId[RNC_MAX_RL_PER_UE]用于记录掉话或者接入失败所在的小区，据此可以确定异常发生时用户所在的小区。确定小区之后就能确定该小区所属的基站。

本步骤所述小区所属基站的与基站控制器之间的传输配置接口的传输配置数据反映的是：该小区所属基站的与基站控制器之间的传输配置接口与设备之间的传输配置关系。在不同的通信系统中，基站的与基站控制器之间的传输配置接口也不相同，例如：在宽带码分多址接入(WCDMA)系统中，基站的与基站控制器之间的传输配置接口称为IUB接口，在全球移动通信系统(GSM)中，基站的与基站控制器之间的传输配置接口称为Abis接口。以WCDMA系统为例，所述传输配置数据就是无线网络控制器(RNC)中IUB接口的传输配置数据。表1示出一个IUB接口的传输配置数据的示例：

NodeB 501060_MaxwellIndustrialBldg_A(IP：172.16.1.22)
				NCP	SAAL 1-0-33	UNI 1-0-11	E1T1 1-0-11(E)
CCP 0	SAAL 1-0-34	UNI 1-0-11	E1T1 1-0-11(E)
				ALCAP 21	SAAL 1-0-35	UNI 1-0-11	E1T1 1-0-11(E)
	AAL2Path 21-1	UNI 1-0-11	E1T1 1-0-11(E)
					IPOAPVC(172.16.1.254)	UNI 1-0-11	E1T1 1-0-11(E)
CELL MaxWell_ACD(ID：48331)
				CELL MaxWell_B(ID：48332)

表1

表1中，第1行为基站的相关信息，包括：IP地址和NodeB的标识。

第2～6行为传输配置信息，每一行从左至右表示一个传输承载关系。例如，第2行表示：NCP承载于SAAL 1-0-33中，而SAAL 1-0-33承载于UNI 1-0-11中，而UNI 1-0-11又承载于E1T1 1-0-11(E)中。

第7～8行表示上述第2～6行的传输配置信息对哪些小区有效。例如：表1中的示例表示：第2～6行的传输配置信息对ID为48331和48332的小区有效。

表1中，SAAL 1-0-34中的3个数字分别表示框号、系统号和链路号；

UNI 1-0-11中的3个数字分别表示框号、槽号和链路号；

E1T1 1-0-11(E)中的3个数字分别表示框号、槽号和链路号，E表示通过电传输，如果是O表示通过光传输。

步骤104：根据所述传输配置数据确定所述接口相应的接口配置对象，并获取所述接口配置对象的告警数据。

本步骤中，根据CHR数据和传输配置数据能够确定发生异常所在的小区，并进一步确定该小区所属基站的IUB接口的接口配置对象，将所述接口配置对象确定为需要获取告警数据的接口配置对象，然后获取所述接口配置对象的告警数据。

本实施例中提供了如下两种方式获取某一接口配置对象的告警数据：

第一种方式：预先对所有告警报文或某一时间段内的告警报文进行预处理，从每个告警报文的定位信息中提取接口配置对象信息，并按照接口配置对象的不同将所述告警报文进行分类，从而确定由每个接口配置对象所产生的告警报文。然后，在本步骤中，根据所述已经确定的由每个接口配置对象所产生的告警报文，获取本步骤需要获取告警数据的那个/那些接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警报文。

第二种方式：在需要获取某一接口配置对象的告警报文时，对所有告警报文、或在呼叫异常发生时、或在呼叫异常发生时的相邻时间段内所产生的告警报文进行处理，从每个告警报文的定位信息中提取接口配置对象信息，并判断所提取的接口配置对象信息是否与所述需要获取告警数据的那个/那些接口配置对象一致，如果一致，则将该报文作为所述需要获取的告警报文之一，获取所有这样的告警报文就构成了本步骤所需要获取的告警数据。

步骤105：对所述接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

本发明是利用设备故障与呼叫异常在时间上的关联性来定位呼叫异常的原因，因此，需要对发生呼叫异常时或发生呼叫异常时附近的一段时间内所产生的告警数据进行告警分析。具体而言，就是根据步骤104所获取的告警数据确定该接口配置对象的故障，并判断所述故障是否能够导致所述呼叫异常，如果是，则将所述呼叫异常的原因定位为所述接口配置对象的所述故障。

例如，如果接口配置对象是E1T1链路，则从告警报文中的定位信息中可以提取E1T1链路信息；判断所述E1T1链路的故障是否能够导致所述呼叫异常，如果是，则将所述呼叫异常的原因定位为所述E1T1链路的故障。

下面针对上述接口配置对象是E1T1的情况，给出一个告警报文的示例，所示告警报文中包含有相应的定位信息：

+++    RNC1        2005-09-21  11:51:21

ALARM  80884       Fault      Major     RNC    1104     Trunk

     Sync serial No.＝139777

          Alarm name＝E1/T1 Alarm Indication Signal

   Alarm raised time＝2005-09-21 11:51:21

       Location info＝Subrack No.＝9，Slot No.＝15，Subsystem No.＝0，Port

                      type＝WBIE electrical port，Link No.＝16

---     END

其中，Location info就是定位信息，从中可以提取出E1T1链路信息，这样，就可以与表1所示IUB接口的接口配置对象关联起来，从而判断传输链路中所存在的故障对呼叫异常的影响。例如，通过对告警数据的分析确定在用户接入失败时，相应的E1T1链路正好发生了闪断告警，则可以确定所述接入失败是由于该闪断所导致的，从而定位出呼叫异常的原因。

如果通过上述步骤105不能定位出呼叫异常的原因，则可以进行背景技术第3步所述路测、信令跟踪等操作，来进一步定位呼叫异常的原因。

图2为本发明实施例中呼叫异常分析装置的组成结构示意图。参见图2，该装置包括：CHR数据分析模块210和异常定位模块220。

其中，CHR数据分析模块210，用于根据CHR数据确定呼叫异常发生时用户所在的小区；

异常定位模块220，用于对所述小区所属基站的接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

所述异常定位模块220中可以包括：

传输配置数据获取子模块221，用于获取所述小区所属基站与基站控制器之间的传输配置接口的传输配置数据，将所述基站的传输配置接口的接口配置对象确定为需要获取告警数据的接口配置对象；

告警数据获取子模块222，用于获取所述需要获取告警数据的接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的的告警数据；

告警数据分析子模块223，用于对所述告警数据进行告警分析，定位呼叫异常的原因。

对应于步骤104所述第一种获取某一接口配置对象的告警数据的方式，所述告警数据获取子模块222中可以包括：

定位信息提取单元224，用于从每个告警报文的定位信息中提取接口配置对象信息，确定由每个接口配置对象所产生的告警报文；

告警报文确定单元225，用于根据所述确定的由每个接口配置对象所产生的告警报文，确定由所述需要获取告警数据的接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警报文。

对应于步骤104所述第二种获取某一接口配置对象的告警数据的方式，所述告警数据获取子模块222中可以包括：

告警报文获取单元226，用于获取在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警报文；

定位信息提取单元224，用于从所述告警报文的定位信息中提取接口配置对象信息；

告警报文确定单元225，用于在判定所提取的接口配置对象信息与所述需要获取告警数据的接口配置对象一致时，将所述提取的接口配置对象信息对应的告警报文作为所述接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警报文之一。

图2所示告警数据分析子模块223中包括：故障定位单元227，用于根据来自于所述告警报文确定单元225的告警报文确定所述接口配置对象的故障，并用于在判定所述故障是能够导致所述呼叫异常时，将所述呼叫异常的原因定位为所述接口配置对象的所述故障。

由上述技术方案可见，本发明实施例提供的进行呼叫异常分析的技术方案，在根据CHR数据无法定位呼叫异常的原因时，采取了根据CHR数据确定呼叫异常发生时用户所在的小区，然后分析该小区所属基站的接口上对应时间点的告警数据，来定位是否是设备故障导致了呼叫异常。可见，本发明实施例所提供的技术方案通过传输配置数据建立起CHR数据与告警数据之间的关联，进而利用CHR数据与告警数据之间的时间关联性，判断设备告警对呼叫异常所产生的影响，定位出设备故障方面的呼叫异常原因。如此，将CHR数据与告警数据结合，可以定位出是否是由于设备故障所引起的呼叫异常，在排除设备故障的可能性之后再进行路测，如此，不必在根据CHR数据无法定位呼叫异常的原因时就直接进行路测、信令跟踪等，从而能够以最小的代价定位出呼叫异常的原因，使得呼叫异常分析的分析效率得到了极大的提高。

以上详细介绍了本发明实施例进行呼叫异常分析的技术方案，下面对本发明实施例预防呼叫异常的技术方案进行详细说明。

没有接到用户投诉，并不代表网络设备没有问题，因此，对呼叫异常进行主动预防是十分必要的。通过主动预防可以发现设备故障和通话质量下降的关系，并通过排除设备故障来改进通话质量。

对应于前述两种预防呼叫异常的技术方案，本发明提供了相应的实施例，下面分别予以介绍：

第一种预防呼叫异常技术方案的实施例：

第1步：对指定时间段内的CHR数据进行统计分析，确定发生呼叫异常最多的N个小区，并确定与所述小区所属的基站。

本步骤中，可以对基站或小区的掉话、接入失败或呼叫异常原因值等各项指标进行TOP N分析，也就是确定发生相应呼叫异常最多的N个小区。

第2步：获取所述小区所属基站的与基站控制器之间的传输配置接口的传输配置数据。

第3步：根据所述传输配置数据确定所述小区所属基站的与基站控制器之间的传输配置接口的接口配置对象，获取所述接口配置对象的告警数据。

第4步：对所述接口配置对象在所述指定时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

在定位出呼叫异常的原因后，可以对所发现的问题进行主动消除，从而实现对呼叫异常的预防。

上述过程也可以反过来，即先分析告警数据再分析CHR数据，从而得到如下第二种预防呼叫异常技术方案的实施例：

第1步：对指定时间段内的告警数据进行统计分析，确定产生告警最多的N个接口配置对象，并确定所述N个接口配置对象对应的基站。

本步骤中，可以对设备故障的各种指标进行统计分析，确定产生告警最多的N个接口配置对象。

第2步：获取与所述基站对应的传输配置数据。

第3步：根据所述传输配置数据获取所述基站对应的小区。

第4步：对所述小区在所述指定时间段内的CHR数据进行分析，确定所述告警对所述呼叫异常的影响。进而对可能导致呼叫异常的因素进行消除。

对应于上述第一种预防呼叫异常的技术方案，本发明实施例提供了一种呼叫异常预防装置，该装置包括：CHR数据分析模块和异常定位模块。

其中，CHR数据分析模块，用于对指定时间段内的CHR数据进行统计分析，确定发生呼叫异常最多的N个小区，将所述小区通知异常定位模块，所述N为大于等于1的整数；

异常定位模块，用于对所述N个小区所属基站的接口配置对象在所述指定时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

所述呼叫异常预防装置中可以包括：

故障消除模块，用于根据异常定位模块所定位的呼叫异常的原因，对引起呼叫异常的故障进行消除。

所述异常定位模块中可以包括：

传输配置数据获取子模块，用于根据发生呼叫异常最多的小区，获取所述小区所属基站与基站控制器之间的传输配置接口的传输配置数据，将所述传输配置数据提供给告警数据获取子模块；

告警数据获取子模块，用于根据所述传输配置数据确定所述基站的传输配置接口的接口配置对象，将所述接口配置对象确定为需要获取告警数据的接口配置对象，并获取所述接口配置对象的告警数据，将所述告警数据提供给告警数据分析子模块；

告警数据分析子模块，用于对所述接口配置对象在所述指定时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

对应于上述第二种预防呼叫异常的技术方案，本发明实施例也提供了一种呼叫异常预防装置，该装置包括：告警数据分析模块和异常定位模块。

其中，告警数据分析模块，用于对指定时间段内的告警数据进行统计分析，确定产生告警最多的N个接口配置对象，并确定所述N个接口配置对象对应的基站，将所述基站通知异常定位模块，所述N为大于等于1的整数；

异常定位模块，用于对所述基站对应的小区在所述指定时间段内的CHR数据进行分析，确定所述告警对所述呼叫异常的影响。

由上述实施例可见，本发明实施例所提供的预防呼叫异常的技术方案，通过传输配置数据建立起了CHR数据与告警数据之间的关联，进而利用CHR数据与告警数据之间的时间关联性，通过统计分析指定时间段内发生呼叫异常最多的N个小区或告警最多的N个接口配置对象来达到主动发现问题，主动消除问题的目的，从而实现对呼叫异常的主动预防，预防大规模呼叫异常的爆发。

本领域普通技术人员可以理解实现上述实施例方法中进行呼叫异常分析的过程以及预防呼叫异常过程可以通过程序指令相关的硬件来完成，所述的程序可以存储于呼叫异常分析装置或呼叫异常预防装置的可读取存储介质中，该程序在执行时执行上述方法中的对应步骤。所述的存储介质可以如：ROM/RAM、磁碟、光盘等。

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

Claims (14)

1.一种进行呼叫异常分析的方法，其特征在于，包括：

根据呼叫历史记录CHR数据确定呼叫异常发生时用户所在的小区；

对所述小区所属基站的接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

2.根据权利要求1所述的进行呼叫异常分析的方法，其特征在于，在所述进行告警分析之前，包括：

获取所述小区所属基站与基站控制器之间的传输配置接口的传输配置数据；

根据所述传输配置数据确定所述基站的传输配置接口的接口配置对象；

获取所述接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警数据。

3.根据权利要求2所述的进行呼叫异常分析的方法，其特征在于，所述获取所述接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警数据包括：

预先从每个告警报文的定位信息中提取接口配置对象信息，确定由每个接口配置对象所产生的告警报文；根据所述确定的由每个接口配置对象所产生的告警报文，获取所述接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警报文。

4.根据权利要求2所述的进行呼叫异常分析的方法，其特征在于，所述获取所述接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警数据包括：

从在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警报文的定位信息中提取接口配置对象信息，判断所提取的接口配置对象信息是否与所述接口配置对象一致，如果一致，则将所述告警报文作为所述接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警报文之

5.根据权利要求2所述的进行呼叫异常分析的方法，其特征在于，所述进行告警分析，定位呼叫异常的原因包括：

根据所述告警数据确定所述接口配置对象的故障，判断所述故障是否能够导致所述呼叫异常，如果是，则将所述呼叫异常的原因定位为所述接口配置对象的所述故障。

6.一种呼叫异常分析装置，其特征在于，包括：

CHR数据分析模块，用于根据CHR数据确定呼叫异常发生时用户所在的小区；

异常定位模块，用于对所述小区所属基站的接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

7.根据权利要求6所述的呼叫异常分析装置，其特征在于，所述异常定位模块中包括：

传输配置数据获取子模块，用于获取所述小区所属基站与基站控制器之间的传输配置接口的传输配置数据，将所述基站的传输配置接口的接口配置对象确定为需要获取告警数据的接口配置对象；

告警数据获取子模块，用于获取所述需要获取告警数据的接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的的告警数据；

告警数据分析子模块，用于对所述告警数据进行告警分析，定位呼叫异常的原因。

8.根据权利要求7所述的呼叫异常分析装置，其特征在于，所述告警数据获取子模块中包括：

定位信息提取单元，用于从每个告警报文的定位信息中提取接口配置对象信息，确定由每个接口配置对象所产生的告警报文；

告警报文确定单元，用于根据所述确定的由每个接口配置对象所产生的告警报文，确定由所述需要获取告警数据的接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警报文。

9.根据权利要求7所述的呼叫异常分析装置，其特征在于，所述告警数据获取子模块中包括：

告警报文获取单元，用于获取在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警报文；

定位信息提取单元，用于从所述告警报文的定位信息中提取接口配置对象信息；

告警报文确定单元，用于在判定所提取的接口配置对象信息与所述需要获取告警数据的接口配置对象一致时，将所述提取的接口配置对象信息对应的告警报文作为所述接口配置对象在呼叫异常发生时或在呼叫异常发生时的相邻时间段内所产生的告警报文之一。

10.根据权利要求8或9所述的呼叫异常分析装置，其特征在于，所述告警数据分析子模块中包括：

故障定位单元，用于根据来自于所述告警报文确定单元的告警报文确定所述接口配置对象的故障，并用于在判定所述故障能够导致所述呼叫异常时，将所述呼叫异常的原因定位为所述接口配置对象的所述故障。

11.一种预防呼叫异常的方法，其特征在于，包括：

对指定时间段内的CHR数据进行统计分析，确定发生呼叫异常最多的N个小区，所述N为大于等于1的整数；

对所述N个小区所属基站的接口配置对象在所述指定时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

12.一种呼叫异常预防装置，其特征在于，包括：

CHR数据分析模块，用于对指定时间段内的CHR数据进行统计分析，确定发生呼叫异常最多的N个小区，所述N为大于等于1的整数；

异常定位模块，用于对所述N个小区所属基站的接口配置对象在所述指定时间段内所产生的告警数据进行告警分析，定位呼叫异常的原因。

13.一种预防呼叫异常的方法，其特征在于，包括：

对指定时间段内的告警数据进行统计分析，确定产生告警最多的N个接口配置对象，并确定所述N个接口配置对象对应的基站，所述N为大于等于1的整数；

对所述基站对应的小区在所述指定时间段内的CHR数据进行分析，确定所述告警对所述呼叫异常的影响，定位呼叫异常的原因。

14.一种呼叫异常预防装置，其特征在于，包括：

告警数据分析模块，用于对指定时间段内的告警数据进行统计分析，确定产生告警最多的N个接口配置对象，并用于确定所述N个接口配置对象对应的基站，所述N为大于等于1的整数；

异常定位模块，用于对所述基站对应的小区在所述指定时间段内的CHR数据进行分析，确定所述告警对所述呼叫异常的影响，定位呼叫异常的原因。

Images