CN1842196B

CN1842196B - 分析呼叫故障原因的方法

Info

Publication number: CN1842196B
Application number: CN2005100639849A
Authority: CN
Inventors: 刘勇; 徐晓琳; 段忠毅; 薛丽军
Original assignee: Huawei Technologies Co Ltd
Current assignee: Global Innovation Polymerization LLC; Gw Partnership Co ltd
Priority date: 2005-03-28
Filing date: 2005-03-28
Publication date: 2010-04-28
Anticipated expiration: 2025-03-28
Also published as: CN1842196A

Abstract

本发明涉及一种分析呼叫故障原因的方法，其核心是：首先根据呼叫用户的标识信息和发生故障的时间从呼叫日志中过滤出相应呼叫用户的呼损日志信息；基于所述呼损日志信息对呼叫故障原因进行分析。通过本发明，能够对所有发生呼叫故障的呼叫用户的故障原因进行分析，解决现有技术中发生呼叫故障的用户被跟踪到的概率很小的问题；另外，当确认所述呼叫故障原因不是根本原因时，本发明能够根据呼损日志的上下文信息分析呼叫用户发生故障的原因，从而解决了现有技术中如果故障日志中只有故障信息，缺乏相关的上下文信息，不利于对问题的根本原因进行分析的问题。

Description

分析呼叫故障原因的方法

技术领域

本发明涉及通讯领域，尤其涉及一种分析呼叫故障原因的方法。

背景技术

在通讯系统中，如WCDMA系统中，通常由于系统的复杂度及无线环境的复杂度，导致呼损和掉话等呼叫故障。当用户因呼叫故障进行投诉时，设备运营商需要分析投诉用户呼叫故障的原因，进而有效地解决用户投诉。

与本发明相关的现有技术一通过呼叫跟踪的方法对呼叫故障原因进行分析，其技术方案为：

操作维护中心(OMC)首先根据用户标识，如国际移动用户标识(International Mobile Subscriber Identification，IMSI)，启动呼叫跟踪，详细记录该呼叫的全部过程，包括接口消息、配置过程、资源状态等等信息；然后根据详细记录来分析呼叫故障。

由上述现有技术一的技术方案可以看出，呼叫跟踪可以获取详细的用户信息，但是如果对每一个呼叫都进行实时跟踪，在一定话务量的情况下会存在跟踪流量太大的情况，从而影响系统的性能，所以一般只是针对有限几个用户进行跟踪。也就是说呼叫跟踪属于事前跟踪，发生呼叫故障的用户被跟踪到的概率很小。如果在用户投诉之后，再对该用户启动呼叫跟踪，就不一定能够跟踪到同样的异常了。

与本发明有关的现有技术二的技术方案为：

首先根据故障日志中投诉用户的用户标识和呼叫故障时间获取相关的日志，然后根据所述日志对呼叫故障原因进行分析。

由现有技术二的技术方案可以看出：如果故障日志中只有故障信息，缺乏相关的上下文信息，也不利于对问题的根本原因进行分析。

发明内容

本发明的目的是提供一种分析呼叫故障原因的方法，通过本发明，解决了现有技术中发生呼叫故障的用户被跟踪到的概率很小的问题。

另外，本发明的目的是提供一种分析呼叫故障原因的方法，通过本发明，解决了现有技术中如果故障日志中只有故障信息，缺乏相关的上下文信息，不利于对问题的根本原因进行分析的问题。

本发明的目的是通过以下技术方案实现的：

本发明提供的一种分析呼叫故障原因的方法，包括：

A、根据呼叫用户的标识信息和发生故障的时间从呼叫日志中过滤出相应呼叫用户的呼损日志信息；所述呼叫日志中包含呼叫用户的用户标识和呼叫详细信息；

B、基于所述呼损日志信息对呼叫故障原因进行分析；

所述步骤B具体包括：

B11、判断呼叫用户发生故障的故障类型是用户活动失败还是异常掉话，如果故障类型是用户活动失败，则用户活动失败的原因就是所述呼叫故障原因；如果故障类型是异常掉话，则执行步骤B12；

B12、根据导致异常掉话的原因对呼损用户发生故障的故障原因进行分析，得到所述呼叫故障原因。

其中，所述步骤A具体包括：

A1、获取呼叫用户的标识信息和发生故障的时间；

A2、根据呼叫用户的标识信息和发生故障的时间从呼叫日志中过滤出相应呼叫用户的呼损日志信息。

其中，所述呼叫用户的呼损日志信息包括：用户标识、呼叫故障类型和呼叫故障原因。

其中，当确认所述呼叫故障原因不是根本原因时，所述步骤B还包括：

B2、根据呼损日志的上下文信息分析呼叫用户发生故障的原因。

其中，所述步骤B12具体包括：

判断导致异常掉话的原因是否为用户活动失败，若是，则用户活动失败的原因为故障原因；否则，掉话的直接原因为故障原因。

其中，所述呼损日志的上下文信息包括：

呼叫用户的当前活动信息、呼叫用户的状态信息、呼叫用户的历史活动信息和/或呼叫用户的终端标识信息。

其中，所述步骤B2具体包括：

根据呼损日志中的所述呼叫用户的当前活动信息，分析呼叫用户发生故障的原因；和/或，

根据呼损日志中的所述呼叫用户的状态信息，分析呼叫用户发生故障的原因；和/或，

根据呼损日志中的所述呼叫用户的历史活动信息，分析呼叫用户发生故障的原因；/和或，

根据获取的呼叫用户的终端标识信息，分析呼叫用户发生故障的原因。

其中，所述用户活动失败故障类型包括：信令连接建立失败、业务指配失败和/或切换失败。

其中，所述异常掉话故障类型包括：业务异常释放和/或信令连接异常释放。

由上述本发明提供的技术方案可以看出，本发明通过首先根据呼叫用户的标识信息和发生故障的时间从呼损日志中过滤出相应呼叫用户的呼损日志信息；然后基于所述呼损日志信息对呼叫故障原因进行分析，从而能够对所有发生呼叫故障的呼叫用户的故障原因进行分析，解决现有技术中发生呼叫故障的用户被跟踪到的概率很小的问题。

另外，当确认所述呼叫故障原因不是根本原因时，本发明能够根据呼损日志的上下文信息分析呼叫用户发生故障的原因，从而解决了现有技术中如果故障日志中只有故障信息，缺乏相关的上下文信息，不利于对问题的根本原因进行分析的问题。

附图说明

图1为本发明提供的实施例的流程图。

具体实施方式

本发明提供了一种分析呼叫故障原因的方法，其核心是：首先根据呼叫用户的标识信息和发生故障的时间从呼叫日志中过滤出相应呼叫用户的呼损日志信息；基于所述呼损日志信息对呼叫故障原因进行分析。

实现本发明的基础，需要呼叫处理模块能够以呼叫用户为单位上报该呼叫用户的故障日志，所述故障日志中包含呼叫故障用户的用户标识和其它呼叫详细信息。其中，所述故障日志中的呼叫详细信息至少包括呼叫故障类型与呼叫故障原因，有时还包括故障的上下文信息。

上述用户标识可以是全球移动用户标识(IMSI)、临时移动用户标识(TMSI AND LAI)、分组临时移动用户标识(PTMSI AND RAI)、全球移动设备标识(IMEI)等等。

所述呼叫故障类型包括信令连接建立失败、业务指配(包括业务建立、业务修改)失败、切换失败、业务异常释放、信令连接异常释放等等。

因为通常用户活动失败是指用户试图发生业务或者移动性的变化，但没有成功，还是保持在活动前的状态，所以将信令连接失败、业务指配失败、切换失败归类为用户活动失败故障类型。

因为通常异常掉话是指由于某种异常导致用户的业务或者信令连接被释放，所以将业务异常释放、信令连接异常释放归类为异常掉话故障类型。

有一种情况，当用户活动失败之后无法恢复到活动前的原始状态，只能释放相应的业务甚至是信令连接，为了分析的方便，将该异常同时视为用户活动失败和异常掉话，异常掉话的直接原因是用户活动失败，根本原因则是用户活动失败的原因。

上述呼叫故障原因包括资源分配失败、协议消息错误、配置失败、传输层异常、用户面异常等等。

上述故障的上下文信息主要包括：呼叫用户的状态信息、当前活动信息和历史活动信息等。其中，所述状态信息是指故障发生时用户的状态，包括RRC连接状态、业务类型、激活集情况、小区信号质量等等。所述当前活动信息是指用户当前活动的配置过程，如消息交互、资源分配等过程。所述历史活动信息是指用户曾经经历过的活动，如业务建立、业务修改、切换等活动。

本方法提供的一种分析呼叫故障原因的方法，如图1所示，其具体实施过程包括：

步骤S101，获取呼叫用户的标识信息和发生故障的时间。

根据投诉用户的手机号码在归属位置寄存器(HLR)中查询到所述呼叫用户的标识信息，如IMSI。并根据投诉用户的投诉获取到其发生故障的时间段。

步骤S102，根据呼叫用户的标识信息和发生故障的时间从呼损日志中过滤出相应呼叫用户的呼损日志信息。

当获取到呼叫用户的标识信息和发生故障的时间段后，在上述呼叫处理模块记录的呼损日志中查找相应呼叫用户的呼损日志信息，并将其过滤出。然后基于所述呼损日志信息对呼叫故障原因进行分析，即基于所述呼损日志信息中的故障类型对所述呼叫用户发生故障的原因进行分析，得到呼叫故障原因；当确认所述呼叫故障原因不是根本原因时，根据呼损日志的上下文信息分析呼叫用户发生故障的原因。具体实施过程包括：

步骤S103，判断呼叫用户发生故障的故障类型是用户活动失败还是异常掉话，如果故障类型是用户活动失败，则执行步骤S104，确认用户活动失败的原因就是故障原因，例如硬切换过程中传输层建立失败，那么故障类型是硬切换失败，故障原因就是传输层资源异常；如果故障类型是异常掉话，则根据导致异常掉话的原因对呼损用户发生故障的故障原因进行分析，得到呼叫故障原因，实现过程如下：

步骤S105，判断导致异常掉话的原因是否为用户活动失败，若是，则执行步骤S104，确认用户活动失败的原因为故障原因，例如硬切换过程中加密配置失败，导致信令连接释放，那么故障类型是信令连接异常释放，故障原因则是加密配置失败；否则，执行步骤S106，确认掉话的直接原因为故障原因，例如用户面故障导致业务异常释放，那么故障类型就是业务异常释放，故障原因则是用户面故障。

经过上述分析过程，可以分析得到呼叫用户发生呼叫故障的故障原因，如果分析人员还希望得到更多的有关呼叫故障的信息，则需要根据其希望得到的信息确认得到的呼叫故障原因是否为根本原因，如果不是根本原因，还需要根据呼损日志的上下文信息进行进一步的分析。例如，如果分析已经得到RRC信令连接释放的原因是信令RB复位，然而分析人员还希望得到“为什么SRB复位”的信息，则需要检查用户日志的其它相关信息。

由上述分析过程可以看出，如果分析人员判断出得到的故障原因是根本原因，就结束分析过程，根据得到的故障原因采取相应的措施排除故障，例如故障是传输层资源故障造成的，则需要检查相应的传输层状况；当确认所述呼叫故障原因不是根本原因时，则需要根据呼损日志的上下文信息对发生故障的原因进行更进一步的分析。因此，本发明提供的第二实施例除包括上述步骤S101至步骤S106的过程，还包括以下具体实施过程：

步骤S107，判断得到的呼叫故障原因是否为根本原因，若是，则执行步骤S108，结束分析过程，根据得到的故障原因采取相应的措施排除故障；否则，执行步骤S109。

步骤S109，根据呼损日志的上下文信息对发生故障的原因进行分析，结合呼损日志的上下文信息对发生故障的原因进行分析的过程具体如下：

结合用户的当前活动信息，分析当前活动中的消息交互、资源分配、配置过程等信息，检查是否存在配置错误、消息信元错误等异常。

分析用户的状态信息，如对用户的业务类型、激活集的小区信息等进行分析，检验呼叫故障是否跟特定的状态相关。如可能是某种业务类型容易导致呼叫故障，或者是某个小区的信号质量太差容易导致呼叫故障，或者是某两个小区间进行切换时容易导致呼叫故障。

分析该用户的历史活动信息，检验呼叫故障是否和用户的历史活动相关。如经过切换之后再进行某种业务的建立过程容易失败。

如果可以获取用户的IMEI的话，可以知道该用户的终端设备类型，以检验该款终端是否存在缺陷。

根据前面的分析结论，得到呼叫用户发生故障的故障原因，针对不同的故障原因采取相应的措施对所述故障进行排除。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应该以权利要求的保护范围为准。

Claims

1.一种分析呼叫故障原因的方法，其特征在于，包括：

B、基于所述呼损日志信息对呼叫故障原因进行分析；

所述步骤B具体包括：

2.根据权利要求1所述的方法，其特征在于，所述步骤A具体包括：

A1、获取呼叫用户的标识信息和发生故障的时间；

3.根据权利要求2所述的方法，其特征在于，所述呼叫用户的呼损日志信息包括：用户标识、呼叫故障类型和呼叫故障原因。

4.根据权利要求3所述的方法，其特征在于，当确认所述呼叫故障原因不是根本原因时，所述步骤B还包括：

5.根据权利要求1所述的方法，其特征在于，所述步骤B12具体包括：

6.根据权利要求4所述的方法，其特征在于，所述呼损日志的上下文信息包括：

7.根据权利要求6所述的方法，其特征在于，所述步骤B2具体包括：

根据呼损日志中的所述呼叫用户的历史活动信息，分析呼叫用户发生故障的原因；和/或，

8.根据权利要求1或5所述的方法，其特征在于，

所述用户活动失败故障类型包括：信令连接建立失败、业务指配失败和/或切换失败；

所述异常掉话故障类型包括：业务异常释放和/或信令连接异常释放。