CN101835124B - 电信网络中业务故障自动诊断的方法及系统 - Google Patents

Abstract

本发明公开了一种电信网络中业务故障自动诊断的方法，包括：收集呼叫过程中的呼叫信息，根据所述呼叫信息及设定的推理机制进行推理，获取呼叫的呼叫模型；将推理得到的呼叫模型与对应的呼叫的实际结果进行比对，不一致时按设定的比对对象将实际对比对象与推理产生的对比对象分别对比，并输出诊断结果。本发明同时公开了一种实现上述方法的电信网络中业务故障自动诊断的系统。本发明能够实现将业务测试结果的识别工作实现自动化。这对于提高集成测试效率和质量都有很大的好处，测试人员仅对测试用例进行设计即可，而比较复杂的结果识别工作，则通过本发明的技术方案自动完成。

Description

电信网络中业务故障自动诊断的方法及系统

技术领域

本发明涉及电信网络中业务故障自动诊断技术，尤其涉及一种下一代电信网络中业务故障自动诊断的方法及系统。

背景技术

在下一代电信网络中的业务故障自动诊断系统中，软交换业务模块的一个集成测试用例的通过，需满足很多的指标要求，例如需满足以下指标要求：业务流程正确，放音正确，呼叫权限正常，业务触发正确，来电显示正常，话单话统正常，资源占用与释放正常，对其他业务没有干扰等。如此多的指标，测试人员会花很多时间来进行验证，并且由于人员经验和精力等限制，可能会遗漏某些测试指标，导致测试用例执行的质量下降。

交换机业务模块软件测试的过程可以归纳为：在一定的呼叫场景下，为用户签约指定的业务，执行设计的呼叫流程，最终判定结果正确成功与否的过程。业务测试最终需要满足一定的指标，或者说成功目标，才可以认为测试用例通过。目前业务模块常见的呼叫成功目标可以分为三类：业务流程类、媒体接续类、外部表象类；其中，

业务流程类：业务流程正确，呼叫权限正常，资源占用与释放正常，用户状态正确，对其他业务没有干扰；

媒体接续类：放音正确，收号正确，媒体接续和切换正确；

外部表象类：原始话单、话务统计、来电显示。

从逻辑的角度来说，如果一个测试用例满足了这些条件，并不能说明该测试用例完全无故障地通过了，因为这些成功目标可能并没有覆盖这次呼叫所有的功能点；但是一个测试用例的通过，必须要满足这些典型的呼叫成功目标。也就是说，满足常见的呼叫成功目标是集成测试用例通过的必要非充分条件。在实际工程测试中，虽然前者是非充分条件，但我们基本上可以信赖该判定条件：即“满足常见的呼叫成功目标”该测试空间，对“集成测试用例通过”该被测试结果具有比较高的置信概率。

下面首先以一个普通接入网关(AG，Access Gateway)呼叫为例，介绍下测试人员识别集成测试结果的一般思路。

测试人员识别集成测试结果的思路一般如下：当前的呼叫场景是普通呼叫；主叫是AG用户，物理号码和逻辑号码分别是111和222；被叫用户是AG用户，物理号码和逻辑号码分别是333和444；呼叫进展情况：通话后挂机，呼叫类别为市话。

根据上述呼叫情况，测试人员会根据各种呼叫成功目标的规则得出该呼叫的预期结果：该呼叫的话单主叫物理号码应该是111，主叫逻辑号码为222；被叫物理号码为333，逻辑号码444；呼叫类别是市话，通话成功，应当产生一张话单。

该呼叫的话统主叫物理号码应该是111，主叫逻辑号码为222；被叫物理号码为333，逻辑号码444；呼叫类别是市话，通话成功，应当产生一张话务统计。

该呼叫的来电显示应该是主叫大号码111。

挂机以后，主被叫占用的协议和业务数据区应该释放掉。

之后，测试人员会观察实际话单、话统、来电显示等信息，看看与预期结果是否一致。

当组网场景比较复杂，或者存在复杂的业务时，测试人员依然采用该过程识别测试的结果：分析呼叫组网和场景、分析用户属性、分析呼叫中的业务、分析呼叫进展情况和通话信息，根据这些信息就得出呼叫中的场景，测试人员根据各种呼叫成功目标的规则可以得到预期结果；然后再与实际测试结果比对，得到当前呼叫是否正确的结论。

根据上述的讨论可以看出：判断测试结果正确性的过程是有规律的，它包含以下几个步骤：

1、采集呼叫信息。对呼叫组网场景、用户属性、业务信息、业务进展情况和通话信息、各种呼叫成功目标进行采集，作为数据之源。

2、推理呼叫模型。根据上述采集的信息，进行推理得到当前呼叫的模型，根据呼叫模型和判定规则表得到当前呼叫中各种成功目标的预期结果。这一步的关键是判定规则表，它的输入是呼叫模型的组成元素，输出是各种成功目标的理论结果。

3、判定呼叫结果。将第二步推理出的成功目标理论结果，与第一步采集的实际结果进行对比，得出当前呼叫是否正确的结论。

如果能自动执行这三个步骤，那么就可以实现集成测试结果的自动识别，从而提高集成测试的质量。但是该过程与测试人员的经验息息相关，一般的软件程序较难实现。

人工智能研究领域中的专家系统理论是一种问题求解工具，适用于需要大量从实际经验中积累起来的知识来求解问题。下面简要介绍下专家系统的相关理论。

基于知识的专家系统是人工智能的一个重要分支。专家系统的能力来自它所拥有的专家知识，知识的表示和推理的方法则提供了应用的机理，这种基于知识的系统设计方法是以知识库和推理机为中心而展开的。

专家系统在生产生活领域应用很广，例如机械部件的诊断、医学知识咨询、市场分析和评估等领域，都有专家系统的身影。总体来说，专家系统是一种问题求解工具，适用于需要大量从实际经验中积累起来的知识来求解问题。

图1为常见的典型的专家系统的结构示意图，如图1所示，专家系统包含知识库、全局数据库、推理机、知识获取机制、解释机制和用户界面等；其中，

知识库是问题求解知识的集合，包含有显式地表示的各种知识块，包含基本事实、规则和其他有关信息。

全局数据库或称工作存储器，是反映当前问题求解状态的集合，用于临时存放求解问题所需的各种初始数据或证据，以及求解期间由专家系统产生的各种中间信息，有时还包含中间假设或中间结论之间的关链关系等。

推理机主要由调度程序与解释程序组成，是实施问题求解的核心执行机构。调度程序依据全局数据库中的当前问题状态及有关信息，按一定的控制策略从知识库中识别和选取可用的知识。解释程序的任务是根据知识的语义，对找到的知识进行解释执行，并把结果记录到全局数据库的适当空间中。

知识获取机制是专家系统中把问题求解的各种专门知识从人类专家的头脑中，或其他知识源那里转换到知识库中来的一个重要机构。

解释机制是专家系统中回答用户询问、对自身的问题求解过程或对自身当前的求解状态提供说明的一个重要机构。

用户界面是专家系统和用户之间进行交互通信和信息交换的媒介。一般采用人机问答的方式进行人机交互。

软交换业务模块的一个集成测试用例的通过，需要满足很多的指标。测试人员会花很多时间来进行验证，并且由于人员经验和精力等限制，可能会遗漏某些测试指标，导致测试用例执行的质量下降。

发明内容

有鉴于此，本发明的主要目的在于提供一种电信网络中业务故障自动诊断的方法及系统，能根据推理理论自动实现对业务故障的自动诊断。

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

一种电信网络中业务故障自动诊断的方法，包括：

收集呼叫过程中的呼叫信息，根据所述呼叫信息及设定的推理机制进行推理，获取呼叫的呼叫模型；

将推理得到的呼叫模型与对应的呼叫的实际结果进行比对，不一致时按设定的比对对象将实际对比对象与推理产生的对比对象分别对比，并输出诊断结果。

优选地，所述推理包含：对呼叫进行业务流程类成功目标、媒体接续类成功目标以及外部表象类成功目标的推理；其中，

业务流程类成功目标至少包含以下一项：业务流程正确，呼叫权限正确，资源、用户状态的占用与释放正确，定时器设置与使用正确；

媒体接续类成功目标是指媒体接续和切换正确，放音正确；

外部表象类成功目标至少包含以下一项：原始话单正确、话务统计正确和来电显示正确。

优选地，所述呼叫过程至少包含以下一项：呼叫的创建阶段、主叫占用阶段、收被叫号码阶段、被叫号码分析阶段、获取被叫信息阶段、主叫准备媒体阶段、被叫鉴权与被叫占用阶段、被叫准备媒体阶段、被叫振铃及主叫听回铃阶段、主叫及被叫通话阶段和通话结束后挂机及释放资源阶段。

优选地，所述诊断结果至少包含以下一项：呼叫结果判定情况、理论与实际的数据、呼叫模型信息、推理的解释；其中，

呼叫结果判定情况至少包含以下一项：进展是否正确、话单比对结果、话统比较结果、来电显示比较结果、资源释放情况、定时器情况；

理论与实际的数据至少包含以下一项：话单、话统、来电显示、资源释放、定时器等外在表现的理论结果，以及数据结果。

推理的解释用于列出当前呼叫的模型，至少包含以下至少一项：呼叫场景、呼叫创建原因、当前呼叫触发的业务、当前呼叫的通话信息、当前呼叫的主被叫信息。

优选地，所述方法还包含：输出诊断结果时还输出推理过程。

优选地，所述收集呼叫过程中的呼叫信息为：收集符合设定条件的呼叫过程中的呼叫信息。

一种电信网络中业务故障自动诊断的系统，包括收集单元、推理单元、比对单元和输出单元；其中，

收集单元，用于收集呼叫过程中的呼叫信息；

推理单元，用于根据所述呼叫信息及设定的推理机制进行推理，获取呼叫的呼叫模型；

比对单元，用于将推理得到的呼叫模型与对应的呼叫的实际结果进行比对，不一致时进一步按设定的比对对象将实际对比对象与推理产生的对比对象分别对比；

输出单元，用于输出诊断结果。

优选地，所述推理包含对呼叫进行业务流程类成功目标、媒体接续类成功目标以及外部表象类成功目标的推理；其中，

业务流程类成功目标至少包含以下一项：业务流程正确，呼叫权限正确，资源、用户状态的占用与释放正确，定时器设置与使用正确；

媒体接续类成功目标是指媒体接续和切换正确，放音正确；

外部表象类成功目标至少包含以下一项：原始话单正确、话务统计正确和来电显示正确。

优选地，所述呼叫过程至少包含以下一项：呼叫的创建阶段、主叫占用阶段、收被叫号码阶段、被叫号码分析阶段、获取被叫信息阶段、主叫准备媒体阶段、被叫鉴权与被叫占用阶段、被叫准备媒体阶段、被叫振铃及主叫听回铃阶段、主叫及被叫通话阶段和通话结束后挂机及释放资源阶段。

优选地，所述诊断结果至少包含以下一项：呼叫结果判定情况、理论与实际的数据、呼叫模型信息、推理的解释；其中，

呼叫结果判定情况至少包含以下一项：进展是否正确、话单比对结果、话统比较结果、来电显示比较结果、资源释放情况、定时器情况；

理论与实际的数据至少包含以下一项：话单、话统、来电显示、资源释放、定时器等外在表现的理论结果，以及数据结果。

推理的解释用于列出当前呼叫的模型，至少包含以下一项：呼叫场景、呼叫创建原因、当前呼叫触发的业务、当前呼叫的通话信息、当前呼叫的主被叫信息。

优选地，所述输出单元输出诊断结果时进一步输出推理过程。

优选地，所述收集单元进一步收集符合设定条件的呼叫过程中的呼叫信息。

本发明中，根据不同的呼叫测试用例设置相应的推理机制，并通过获取设定条件呼叫的呼叫信息，利用设定的推理机制进行推理，并与实际的呼叫结果进行比对，从而获取当前呼叫过程中的业务故障。本发明无需测试人员的干预而自动完成业务故障的定位，保证了故障检测的完整性及可靠性。并且，一旦测试用例的推理机制设定完毕，可应用于该呼叫用例的所有呼叫。

附图说明

图1为常见的典型的专家系统的结构示意图；

图2为本发明电信网络中业务故障自动诊断的方法的流程图；

图3为本发明在呼叫流程中采集呼叫信息的流程图；

图4为无条件前传业务呼叫的业务故障检测示意图；

图5示出了在图4所示业务呼叫中的计费话单的故障检测流程图；

图6是本发明中目标、推理规则及外在表象的关系示意图；

图7为本发明电信网络中业务故障自动诊断的系统的组成结构示意图。

具体实施方式

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

图2为本发明电信网络中业务故障自动诊断的方法的流程图，如图2所示，本发明电信网络中业务故障自动诊断的方法包含以下步骤：

步骤201，识别当前呼叫是否匹配跟踪条件；

交换机中呼叫量很大，本发明并非对所有的呼叫都采集呼叫数据。因此首先需要能设定一定的匹配条件，来筛选出需要采集信息的呼叫，该功能类似于交换机中常见的信令跟踪条件设置。可以按照用户号码、网关节点、模块号、中继群号等作为呼叫的跟踪匹配条件。只要呼叫能匹配上相应的条件，就对该呼叫进行跟踪，并采集呼叫相关信息。需要说明的是，本发明所需采集的信息是事先设定的，即根据具体的推理规则，设定相应的呼叫采集信息。本领域技术人员应当理解，实现呼叫信息采集的方式是容易实现的，并且，各信息所使用的采集方式是不同的，例如呼叫号码信息可通过终端用户的身份标识信息或终端用户的端口信息获取，被叫号码信息可通过主叫的呼叫请求消息而获取。

步骤202，采集有效的呼叫信息；

如果某个呼叫需要采集呼叫信息，那么需要在呼叫流程的关键点上，记录当前呼叫组网场景、用户属性、业务信息、业务进展情况和通话信息，记录各种呼叫成功目标的实际情况。关于如何采集呼叫的相关信息，可参照下文附图3中的具体流程而理解。

步骤203，将采集信息记录到独立的数据区中；

从呼叫流程中采集最原始的数据，需要存储在独立的数据区中。在通话结束，根据呼叫模型和推理规则得出理论结果之后，应该将理论结果也记录在呼叫诊断信息结构体中。

呼叫诊断信息的结构体中，至少包含以下信息：

1)诊断信息数据区标示，数据区索引等内容；

2)呼叫场景与组网信息；

3)呼叫中触发的业务信息；

4)主叫和被叫用户号码和协议等信息；

5)通话相关信息、通话类别、通话进展等；

6)成功目标理论结果，根据上述信息和规则推理得到；

7)成功目标实际结果，根据实际采集得到；

8)呼叫模型、检测结果、检测依据；

步骤204，业务流程类成功目标的推理工作；

推理的主要目是实现“集成测试结果正确”的目标，集成测试结果正确的目标被分解为“业务流程正确”、“媒体接续正确”和“外部表现正确”这三个子目标，这三个子目标又可以根据测试需要继续分解为更为细化的目标。这些细化的目标均与一系列外在表象有关系，这个关系就是目标各自的规则。本领域技术人员应当理解，由于测试要求及测试手段的不同，测试子目标的划分有所不同。图6是本发明中目标、推理规则及外在表象的关系示意图，如图6所示，图中各个元素的解释如下：

目标：呼叫中的各种成功标志正确与否，是故障识别工作的目标；每一个成功标志都是一个目标，都与一系列外在表象相关；

外在表象：呼叫中的组网场景、业务信息、用户属性、业务进展情况和通话信息等内容，是故障识别工作的外在表象；在呼叫中，可以采集到这些数据，作为求解问题的初始数据；

推理规则：呼叫中的各种成功标志的设计方案，是故障识别工作的推理规则；这些规则与初始数据和目标结果相关，可以写成代码。

根据分析，所有的子目标均与呼叫中一定的外在表象相关，工作的重点就在于找到目标与外在表象之间的联系，即判别规则。

业务流程类成功目标包括以下几个子目标：业务流程正确，呼叫权限正确，资源、用户状态的占用与释放正确，定时器设置与使用正确。媒体接续类成功目标包括以下几个子目标：放音正确，收号正确，媒体接续与切换正确。外部表现类成功目标包括以下几个子目标：原始话单、话务统计、来电显示、业务观察、告警信息。

各个目标都有相应的判别规则，诊断系统的设计者需要能找出这种规则，并且用代码的方式表达出来。最后将推理的结果存储在诊断信息的理论结果中，留待后续比对处理。

在推理过程中，可以在每一步推理规则上增加标记，表示是根据什么规则得出如此判断的，最后将诊断推理规则一并输出出来，给测试人员参考。本发明中的推理，即是对呼叫进行业务流程类成功目标、媒体接续类成功目标以及外部表象类成功目标的推理。

业务流程类成功目标包含以下几个子目标：业务流程正确，呼叫权限正确，资源、用户状态的占用与释放正确，定时器设置与使用正确。其中：

业务流程正确：包含当前呼叫进展是否正确，广义上还应该包含业务触发与实现是否符合要求，业务的优先级是否判断正确等。

呼叫权限正确：包含两个因素，当前呼叫模型、呼叫的权限模板，即一定的呼叫模型是否符合权限模板的限制。

资源、用户状态的占用与释放：通话中的资源包含数据区资源、中继资源、音资源，用户状态分为空闲、忙、闭塞等。通话中会占用一定的资源和用户状态，在通话结束后需要释放这些资源和状态，

本发明中，各个目标都有相应的判别规则，本发明的推理规则即是确定出这种判别规则，并且用代码的方式将其表达出来。需要说明的是，针对不同的判别目标，推理规则并不相同，推理规则即是根据模拟呼叫过程所能实现的目标。本领域技术人员应当理解，设置推理规则并将其转换为可执行的推理应用软件是容易实现的。相对于根据具体的测试项目生成对应的测试用例。最后将推理的结果存储在诊断信息的理论结果中，留待后续比对处理。在推理过程中，可以在每一步推理规则上增加标记，表示是根据什么规则得出如此判断的，最后将诊断推理规则一并输出，供测试人员参考。

步骤205，媒体接续类成功目标的推理工作；

媒体接续类成功目标是指媒体接续和切换正确，放音正确。在通话中，根据业务流程需要，会切换通话中的媒体信息。例如切换彩铃媒体，切换转接的媒体等。由于业务的复杂性，每种业务下的媒体接续与切换情况很难自动检测。但是通话态下的媒体情况可以检测：在呼叫进入通话态后，对比主叫和被叫用户的媒体的端口号和IP地址，检查媒体收发状态。这可以满足大多数的应用。

步骤206，外部表象类成功目标的推理工作；

外部表象类成功目标包含以下几个子目标：原始话单、话务统计、来电显示等；其中：

原始话单正确：原始话单按照业务的需求，记录通话中的重要信息；其设计的主要目标是为了局方进行计费和话单分拣的工作；原始话单与所有的业务均有关系，规则一般比较复杂。

话务统计正确：话务统计消息按照业务的需求，记录通话中的重要信息；其设计的主要目标是反映软交换的性能以及话务量等信息；话务统计与所有的业务均有关系，但其规则相比话单要简单。

来电显示正确：来电显示功能告诉被叫用户是谁发起的呼叫，并且在用户对未接来电进行回拨时，作为被叫号码使用，来电显示是影响用户体验的重要因素。

步骤207，呼叫结果判定；

将步骤204～步骤206步推理出的成功目标理论结果，与步骤202采集的成功目标实际结果进行对比，得出当前呼叫是否正确的结论；如果两者不一致，那么业务故障。

在设计结果判定模块时，需要关注以下的内容：

1)选择重要的字段进行信息比对：以交换机产生的原始话单为例，话单与几乎所有的业务都有关系，并且原始话单中字段非常多，如果对所有的项都做验证，工作非常大且没有必要。需要筛选出主要的功能字段来进行比对。

2)记录推理流程：在给出理论结果之后，需要能给出推理的依据，给测试人员进行参考。推理依据需要在推理过程中进行记录，记录每一个步骤中的分支。

3)理论结果与实际结果的比对：在诊断信息数据区中记录理论结果和实际结果，将理论结果和实际结果进行比较，就得出了结果。需要注意的是，理论结果仅仅作为参考，在结果输出模块中需要列出理论结果和实际结果的数据，供测试人员参考。

步骤208，输出判定的结果；

输出的内容包含：呼叫结果判定情况、理论与实际的数据、呼叫模型信息、推理的解释；其中：

呼叫结果判定情况：进展是否正确、话单比对结果、话统比较结果、来电显示比较结果、资源释放情况、定时器情况；

理论与实际的数据：话单、话统、来电显示、资源释放、定时器等外在表现的理论结果，以及数据结果，全部列出来供测试人员参考。

列出推理的解释：列出当前呼叫的模型，包含呼叫场景、呼叫创建原因、当前呼叫触发的业务、当前呼叫的通话信息、当前呼叫的主被叫信息等。

步骤209，自我维护功能

对推理过程中存储的数据区进行维护，对数据区建立和释放进行统一处理；另外，维护一套定时器处理机制，定时对推理数据区进行维护。

图3为本发明在呼叫流程中采集呼叫信息的流程图，如图3所示，本发明需在呼叫流程中的以下阶段进行信息采集：

301.呼叫的创建阶段

指交换机接收到一个创建呼叫的请求。在呼叫流程的此处可以记录呼叫创建原因(用户发起呼叫、多方业务发起呼叫)，主叫协议类型、主叫号码等信息。

302.主叫占用阶段

交换机为本次呼叫的主叫侧分配资源，包含数据区资源，并且占用用户状态。在呼叫流程的此处可以记录主叫用户的内部识别目标和用户状态。

303.收被叫号码阶段

交换机向主叫网关放拨号音，下号码图表，由网关执行收被叫号码的操作。在呼叫流程的此处可以记录主叫拨打的被叫号码，此处收集的被叫号码一般都是逻辑号码。

304.被叫号码分析阶段

号码分析功能是对主叫拨打的号码进行字冠分析，以获取该号码的相关属性，并做相应的处理。在呼叫流程的此处可以记录分析得到的通话类别。

在号码分析之后，一般会有一个查询HLR的过程，HLR会返回主叫和被叫用户物理号码和逻辑号码的对应关系，需要记录到诊断数据区中。

305.获取被叫信息阶段

交换机在主叫侧会尝试获取被叫用户在系统中的信息，例如被叫所在网关节点、协议类型等信息。这些信息需要记录到诊断数据区中。

306.主叫准备媒体阶段

交换机为主叫用户准备一次通话所需要的媒体资源，媒体信息通常是以SDP的方式来描述的。媒体信息需要记录到诊断数据区中，以备后面检验主被叫媒体时使用。

307.被叫鉴权与被叫占用阶段

交换机为本次呼叫的被叫侧分配资源，包含数据区资源，并且占用用户状态。在呼叫流程的此处可以记录被叫用户的内部识别目标和用户状态。

308.被叫准备媒体阶段

交换机为被叫用户准备一次通话所需要的媒体资源，媒体信息通常是以SDP的方式来描述的。媒体信息需要记录到诊断数据区中，以备后面检验主被叫媒体时使用

准备媒体之后，交换机将发起一个出局呼叫的消息，将呼叫信息封装成标准的局间信令，发送到被叫所在的网关。在呼叫流程的此处可以记录局间信令中的号码信息，作为后续比对结果时，作为实际数据。

309.被叫振铃，主叫听回铃阶段

被叫用户振铃，主叫侧听回铃音。此处可以记录被叫用户已经发生振铃的呼叫进展目标。

310.主叫和被叫通话阶段

被叫用户摘机应答，主叫和被叫进入通话的状态。此处可以记录被叫用户已经发生振铃的呼叫进展目标。

311.通话中主叫或被叫拍叉簧

如果触发多路呼叫，与后一路呼叫建立联系。

312.通话结束后挂机，释放资源阶段

通话结束。此处可以采集呼叫资源是否已经释放，用户状态是否正常。并且采集原始话单、话务统计等外部表象的实际数据。

数据采集完成后，即可开始三类成功目标(业务流程、媒体接续、外部表象)的推理工作，将推理结果与实际结果进行对比，从而得到测试用例是否正确的结论。

图4为无条件前传业务呼叫的业务故障检测示意图，如图4所示，以软交换系统中常见的无条件前传业务呼叫作为例子，介绍了该业务的呼叫场景，与呼叫信息采集、成功目标的实际结果等内容。图5示出了在图4所示业务呼叫中的计费话单的故障检测流程图。

图4中的呼叫模型为：主叫用户A，物理号码111，逻辑号码222；被叫用户B，物理号码333，逻辑号码444；前转用户C，物理号码555，逻辑号码666；B用户签约无条件前转业务，前转号码为C用户逻辑号码666。

主叫A拨打B用户的逻辑号码444呼叫用户B；B有无条件前转业务，触发多方后创建到C用户逻辑号码666的新呼叫；即A B(CFU)C。当前业务存在两路呼叫A B、B C。

以下以计费话单的故障检测流程为例进一步阐明本发明技术方案的实质。

如图5所示，计费话单的故障检测流程具体包括以下步骤：

步骤501，确定本次呼叫创建的原因；

某路话单的模型与当前呼叫创建的原因有很大关系，根据当前呼叫创建的原因，基本上就可以决定当前呼叫产生话单的模型。例如，如果当前呼叫是前转业务创建的，那么与普通话单相比，除了主被叫号码之外，还需要额外填写连接号码和原被叫号码，而这些号码是与前一路呼叫的信息相关的。

第一路呼叫A B呼叫为本局用户起呼，根据“呼叫创建原因”表中的判别规则，话单模型应该是：主叫A，被叫B，拨号B，没有连接号码和原被叫号码；

第二路呼叫B C呼叫为前转多方创建，根据表中的判别规则，话单模型应该是：主叫B，被叫C，无拨号号码，连接号码为前一路主叫A，原被叫号码为前一路被叫B。

步骤502，确定当前呼叫触发的业务；

当前呼叫触发的业务会影响话单中的补充业务目标、话单类别(普通话单、智能话单、转接构造话单、一号通构造话单)等因素；

第一路呼叫A B，此路呼叫还触发了无条件前转业务，因此不需要检测来电显示。需要建立与后一路呼叫的联系。

第二路呼叫B C，触发了无条件前转业务，因此不需要检测来电显示。需要建立与前一路呼叫，和后一路呼叫的联系。

步骤503，确定当前呼叫的通话信息；

如果在呼叫过程中如果查询了HLR或者号码变换等内容，业务模块的信令号码、计费号码、逻辑号码等号码的性质会有变化。

第一路呼叫A B，主被叫都查询了HLR得到了主被叫逻辑号码，号码分析结果市话；

第二路呼叫B C，主被叫都查询了HLR得到了主被叫逻辑号码，号码分析结果长途；

步骤504，根据优先级确定当前呼叫的主被叫号码信息；

根据话单中各号码段填写的优先级，可以推理出细化后三路呼叫话单填写的模型：

第一路呼叫A B，话单理论模型：

主叫物理：CurrentCall.tCaller.bPhyNum；主叫逻辑：CurrentCall.tCaller.bLogicNum；

被叫物理：CurrentCall.tCalled.bPhyNum；被叫逻辑：CurrentCall.tCalled.bLogicNum；

拨号号码：CurrentCall.bDialingNum；连接号码：无；原被叫：无；

业务目标：CFU、缩位，呼叫类别市话。主被叫网关、协议类型等取当前呼叫中相关信息；

第二路呼叫B C，话单理论模型：

主叫物理：CurrentCall.tCaller.bPhyNum；主叫逻辑：CurrentCall.tCaller.bLogicNum；

被叫物理：CurrentCall.tCalled.bPhyNum；被叫逻辑：CurrentCall.tCalled.bLogicNum；

连接物理：PreviousCall.tCaller.bLogicNum；连接逻辑：PreviousCall.tCaller.bPhyNum；原被叫：PreviousCall.tCalled.bLogicNum；拨号号码：无；

呼叫类别市话。主被叫网关、协议类型等取当前呼叫中相关信息；

步骤505，根据话单的理论模型和采集的实际数据，合成出话单的理论结果。

第一路呼叫A B，话单的理论结果：

主叫物理：111；主叫逻辑：222；被叫物理：333；被叫逻辑：444；

拨号号码：444；连接号码：无；原被叫：无；

呼叫类别市话。主被叫网关、协议类型等取当前呼叫中相关信息；

第二路呼叫B C，话单的理论结果：

主叫物理：333；主叫逻辑：444；被叫物理：555；被叫逻辑：666；

连接物理：111；连接逻辑：222；原被叫：444；拨号号码：无；

呼叫类别市话。主被叫网关、协议类型等取当前呼叫中相关信息；

如图4所示，给出了该例子的实际呼叫模型与话单等外在表现的实际测试结果。对比话单的理论结果与实际结果可见，两者非常吻合，因此可以使用诊断信息来对测试结果进行验证。

图7为本发明电信网络中业务故障自动诊断的系统的组成结构示意图，如图7所示，本发明电信网络中业务故障自动诊断的系统包含收集单元60、推理单元71、比对单元72和输出单元73；其中，

收集单元70，用于收集呼叫过程中的呼叫信息；

推理单元71，用于根据所述呼叫信息及设定的推理机制进行推理，获取呼叫的呼叫模型；

比对单元72，用于将推理得到的呼叫模型与对应的呼叫的实际结果进行比对，不一致时进一步按设定的比对对象将实际对比对象与推理产生的对比对象分别对比；

输出单元73，用于输出诊断结果。

上述推理包含对呼叫进行业务流程类成功目标、媒体接续类成功目标以及外部表象类成功目标的推理；其中，

业务流程类成功目标至少包含以下一项：业务流程正确，呼叫权限正确，资源、用户状态的占用与释放正确，定时器设置与使用正确；

媒体接续类成功目标是指媒体接续和切换正确，放音正确；

外部表象类成功目标至少包含以下一项：原始话单正确、话务统计正确和来电显示正确。

上述呼叫过程至少包含以下一项：呼叫的创建阶段、主叫占用阶段、收被叫号码阶段、被叫号码分析阶段、获取被叫信息阶段、主叫准备媒体阶段、被叫鉴权与被叫占用阶段、被叫准备媒体阶段、被叫振铃及主叫听回铃阶段、主叫及被叫通话阶段和通话结束后挂机及释放资源阶段。

上述诊断结果至少包含以下一项：呼叫结果判定情况、理论与实际的数据、呼叫模型信息、推理的解释；其中，

呼叫结果判定情况至少包含以下一项：进展是否正确、话单比对结果、话统比较结果、来电显示比较结果、资源释放情况、定时器情况；

理论与实际的数据至少包含以下一项：话单、话统、来电显示、资源释放、定时器等外在表现的理论结果，以及数据结果，全部列出来供测试人员参考。

推理的解释用于列出当前呼叫的模型，至少包含以下至少一项：呼叫场景、呼叫创建原因、当前呼叫触发的业务、当前呼叫的通话信息、当前呼叫的主被叫信息等。

上述输出单元73输出诊断结果时进一步输出推理过程。

上述收集单元70进一步收集符合设定条件的呼叫过程中的呼叫信息。

本领域技术人员应当理解，图7所示的电信网络中业务故障自动诊断的系统是为实现前述的电信网络中业务故障自动诊断的方法而设计的，图7所示系统中各处理单元的功能可参照前述方法的描述而理解，各处理单元的功能可通过运行于处理器上的程序而实现，也可通过具体的逻辑电路而实现。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (12)

1.一种电信网络中业务故障自动诊断的方法，其特征在于，所述方法包括：

收集呼叫过程中的呼叫信息，根据所述呼叫信息及设定的推理机制进行推理，获取呼叫的呼叫模型；

将推理得到的呼叫模型与对应的呼叫的实际结果进行比对，不一致时按设定的比对对象将实际对比对象与推理产生的对比对象分别对比，并输出诊断结果。

2.根据权利要求1所述的方法，其特征在于，所述推理包含：对呼叫进行业务流程类成功目标、媒体接续类成功目标以及外部表象类成功目标的推理；其中，

业务流程类成功目标至少包含以下一项：业务流程正确，呼叫权限正确，资源、用户状态的占用与释放正确，定时器设置与使用正确；

媒体接续类成功目标是指媒体接续和切换正确，放音正确；

外部表象类成功目标至少包含以下一项：原始话单正确、话务统计正确和来电显示正确。

3.根据权利要求1所述的方法，其特征在于，所述呼叫过程至少包含以下一项：呼叫的创建阶段、主叫占用阶段、收被叫号码阶段、被叫号码分析阶段、获取被叫信息阶段、主叫准备媒体阶段、被叫鉴权与被叫占用阶段、被叫准备媒体阶段、被叫振铃及主叫听回铃阶段、主叫及被叫通话阶段和通话结束后挂机及释放资源阶段。

4.根据权利要求1所述的方法，其特征在于，所述诊断结果包含以下的至少一项：呼叫结果判定情况、理论与实际的数据、呼叫模型信息、推理的解释；其中，

呼叫结果判定情况至少包含以下一项：进展是否正确、话单比对结果、话统比较结果、来电显示比较结果、资源释放情况、定时器情况；

理论与实际的数据至少包含以下一项：话单、话统、来电显示、资源释放、定时器等外在表现的理论结果，以及数据结果；

推理的解释用于列出当前呼叫的模型，至少包含以下一项：呼叫场景、呼叫创建原因、当前呼叫触发的业务、当前呼叫的通话信息、当前呼叫的主被叫信息。

5.根据权利要求1所述的方法，其特征在于，所述方法还包含：输出诊断结果时还输出推理过程。

6.根据权利要求1所述的方法，其特征在于，所述收集呼叫过程中的呼叫信息为：收集符合设定条件的呼叫过程中的呼叫信息。

7.一种电信网络中业务故障自动诊断的系统，其特征在于，所述系统包括收集单元、推理单元、比对单元和输出单元；其中，

收集单元，用于收集呼叫过程中的呼叫信息；

推理单元，用于根据所述呼叫信息及设定的推理机制进行推理，获取呼叫的呼叫模型；

比对单元，用于将推理得到的呼叫模型与对应的呼叫的实际结果进行比对，不一致时进一步按设定的比对对象将实际对比对象与推理产生的对比对象分别对比；

输出单元，用于输出诊断结果。

8.根据权利要求7所述的系统，其特征在于，所述推理包含对呼叫进行业务流程类成功目标、媒体接续类成功目标以及外部表象类成功目标的推理；其中，

业务流程类成功目标至少包含以下一项：业务流程正确，呼叫权限正确，资源、用户状态的占用与释放正确，定时器设置与使用正确；

媒体接续类成功目标是指媒体接续和切换正确，放音正确；

外部表象类成功目标至少包含以下一项：原始话单正确、话务统计正确和来电显示正确。

9.根据权利要求7所述的系统，其特征在于，所述呼叫过程至少包含以下一项：呼叫的创建阶段、主叫占用阶段、收被叫号码阶段、被叫号码分析阶段、获取被叫信息阶段、主叫准备媒体阶段、被叫鉴权与被叫占用阶段、被叫准备媒体阶段、被叫振铃及主叫听回铃阶段、主叫及被叫通话阶段和通话结束后挂机及释放资源阶段。

10.根据权利要求7所述的系统，其特征在于，所述诊断结果至少包含以下一项：呼叫结果判定情况、理论与实际的数据、呼叫模型信息、推理的解释；其中，

呼叫结果判定情况至少包含以下一项：进展是否正确、话单比对结果、话统比较结果、来电显示比较结果、资源释放情况、定时器情况；

理论与实际的数据至少包含以下一项：话单、话统、来电显示、资源释放、定时器等外在表现的理论结果，以及数据结果；

推理的解释用于列出当前呼叫的模型，至少包含以下一项：呼叫场景、呼叫创建原因、当前呼叫触发的业务、当前呼叫的通话信息、当前呼叫的主被叫信息。

11.根据权利要求7所述的系统，其特征在于，所述输出单元输出诊断结果时进一步输出推理过程。

12.根据权利要求7所述的系统，其特征在于，所述收集单元进一步收集符合设定条件的呼叫过程中的呼叫信息。

Images