CN107347016B - 一种信令流程模型识别方法及异常信令流程辨识方法 - Google Patents

Abstract

本发明公开了一种信令流程模型识别方法及异常信令流程辨识方法，根据3GPP规范的信令流程，抽象出用于识别流程的信令流程模型。抽象出信令流程后，对关键信令进行标识定义，然后建立信令流程模型，通过信令流程模型对信令进行识别。再将异常流程识别出来，并提取出异常信息。本发明将网元间的信令流程识别出来，然后在此基础上，将异常流程提取出来，将极大的提高系统信令分析、辅助定位、解决问题的能力。

Description

一种信令流程模型识别方法及异常信令流程辨识方法

技术领域

本发明涉及通讯的技术领域，具体地说是通讯网管中信令的跟踪及识别技术。

背景技术

在通信领域中，信令跟踪系统得到广泛使用，信令跟踪系统用于跟踪各种信令的流程，它是网管系统中日常维护非常重要的一个组成部分，为网管维护人员在日常维护中提供了分析问题、定位问题、解决问题的方法。

目前的信令跟踪系统主要是将网元产生的信令采集并展示给用户，用户只能逐条查看单网元上报的信令，然后根据业务知识将孤立的信令串联起来。这样的方式明显的增大了使用系统的难度(只有很有经验的人员才能熟练的使用)，既不利于对流程的分析，也不利于问题的定位，同时在使用系统与其他人员交流的时候，也增加了难度。如果能够将网元间的信令流程识别出来，然后在此基础上，将异常流程提取出来(在实际的使用过程中，用户最希望的是借助系统，能够快速的定位问题)，将极大的提高系统辅助定位、分析、解决问题的能力。

专利申请201310585403.2公开了一种信令流程分析系统和方法，其包括：信令采集步骤、信令预处理步骤、信令流程分析步骤、状态机编辑步骤、脚本编辑步骤、脚本解释步骤；以及一种信令流程分析系统，其包括：信令采集模块、信令预处理模块、信令流程分析模块、状态机编辑模块、脚本编辑模块、脚本解释模块。其中信令流程分析步骤或模块结合lua脚本的自定义状态机，接收、分析和计算信令，并将自定义状态机的最终状态作为分析结果输出至一应用使用。然而该方法主要是用于分析和提取信令，通过lua脚本来定义信令流程的判定规则，以直观的图形界面来创建编辑状态机，对异常信令缺乏一个判断规则，难以准确识别异常的信令流程。

专利申请201510427534.7公开了一种信令流程的识别方法及装置。用于在信令流程分析过程中，提高信令流程的识别准确性。综上所述，本发明实施例中，预先将每一个信令视为若干元素的组合，结合信令的交互规则，提取出各类典型信令流程的综合特征，生成相应的配置文件集合，接着，基于实际获得的信令交互数据，提取出信令交互数据中包含的每一条信令的综合特征，再基于提取出的综合特征，采用获得的配置文件集合在信令交互数据中进行匹配，识别出与配置文件集合匹配的目标信令流程。这样，当目标信令流程变更时，只需调整配置文件，无需修改代码，从而大大提高了信令流程识别的灵活性、准确性，以及加快了处理速度，并且有效降低了软件的运维成本。该方法只是通过对信令的判断识别调整配置文件，对于异常信令并无处理方法。

发明内容

本发明的目的在于，提供一种信令流程模型识别方法及异常信令流程辨识方法，该方法用于信令跟踪系统，用来解决现有信令跟踪系统中只能查看单条信令，不能查看信令流程的问题。

本发明的另一个目的在于提供一种信令流程模型识别方法及异常信令流程辨识方法，该方法能够快速提取出信令流程，并识别出异常信令流程，能够快速的定位到发生问题的网元以及问题产生的原因，提高排除问题的效率，便于日常的系统维护。

基于此，本发明是通过以下方式实现的。

一种信令流程模型的识别方法，其特征在于该方法梳理各业务操作对应的信令流程，进而抽象出信令流程模型，主要内容包括：

抽象信令流程：包括信令流程的起始信令、结束信令、业务操作名称、可能包含的子流程；

抽象关键信令：针对信令流程模型中的起始信令、结束信令进行标识定义，用于信令识别；主要包括信令对应的信令名称、事件号、协议、上报网元类型、发送信令还是接受信令等信息；

抽象出信令流程后，对关键信令进行标识定义，然后建立信令流程模型，通过信令流程模型对信令进行识别。

所述信令流程模型，包括：

起始信令：信令流程的触发信令，也可以说是流程的第一条信令；

中间信令：除起始、结束信令之外的，在网元间传递和转换的信令，该部分信令的特点是某些信令会根据不同的组网、业务等情况，会条件的出现；

结束信令：信令流程的最后一条信令，该条信令标识流程的完结。

所述中间信令，其可以分成两大类：流程必定包含的信令和流程可能包含的信令。

所述方法，在关键信令和信令流程模型的基础上，依据网元上报的信令，进行信令流程提取。所述信令流程提取是逐条遍历信令文件中的所有信令，匹配出能和配置的信令流程模型匹配的起始信令，然后逐条遍历出能和配置的信令流程模型匹配的结束信令，结束信令有可能有多条，需要向后遍历出最后一条结束信令。

对于已识别的流程，记录流程的起始信令和结束信令的索引，便于展示单元进行流程的绘制和展示。

所述方法，对于代表业务失败的信令(都包含于中间信令中)一般通过信令事件名称或者信令的原因码进行标识，依据3GPP规范整理业务操作可能的失败事件名称以及失败原因码的取值列表，遍历并解析信令文件，依据整理的失败列表识别异常信令。在信令流程提取出来的基础上，将包含异常信令的信令流程进行标识，便于用户第一时间识别异常。

同时，识别没有关联信令的单点信令，如果信令的发送或者接收网元为系统已经接入的网元，有可能对端网元漏报了信令，也可能网元发了，但是信令跟踪系统没有接收到。对于单点信令，使用虚线进行标识。

所述方法，具体包括如下步骤：

遍历采集到的信令数据集合；

判断提取出的集合中的一条信令是否能和某个配置的业务信令流程的起始信令相匹配，如果不能，则继续遍历采集到的信令数据集合；

如果信令是某个业务流程的起始信令，则找到与起始信令对应的结束信令组；

遍历结束信令组，从若干结束信令中提取出一条失败信令，然后从信令集合中当前信令的下一条开始索引结束信令，如果没有索引到结束信令，则继续遍历结束信令，直到遍历结束；

如果索引到了结束信令，则依据起始信令编号和结束信令编号将这一闭区间的信令全部提取出来；

流程清洗；利用之前业务流程中定义的信令(起始、结束信令以及中间信令)对流程进行清洗，将流程中不在其中的信令移除；

将清洗后的信令提取出来，并将起始、结束信令打上标记，构建信令流程；

继续遍历采集到的信令数据集合，直到遍历到最后一条信令，将所有的信令流程都提取出来为止。

在流程清洗前，先对多个网元上报的信令进行排序，排序主要的依据是单网元信令的上报顺序，以及信令的时间戳，由于网元时间的不一致以及业务的复杂性(比如正在做数据业务，之间来了电话)，都会导致提取的流程中可能会夹杂不是本流程的信令，将流程中不是本流程的信令移除。

所述遍历采集到的信令数据集合，不是从结束信令开始遍历，而是从起始信令的下一条开始。

一种异常信令流程辨识方法，其特征在于该方法的步骤如下：

提取出的信令流程；

遍历信令流程中包含起始、结束信令区间的信令；

通过一条信令判断信令是否失败，将流程标识为异常流程；

遍历该流程中所有的信令；

流程遍历结束后，获取并遍历该业务流程模型中定义的中间信令中必有部分的信令；

如果中间信令必有部分的信令中的一条在信令流程中能够匹配到，则继续遍历，如果匹配不到，则判断该条信令的发送网元类型在信令流程中是否只包含一个该类型被跟踪的网元，如果只有一个，则能确定该网元缺失信令，如果有多个，则只能确定该流程中缺失该条信令，并将流程标识为异常流程；

待流程遍历结束后，利用MD5将发送和接收的信令关联起来；

在关联的过程中辨识是否存在不能匹配的信令，或称单点信令，如果该信令所对应的源或者目的IP是系统中跟踪网元的IP，则说明流程异常，标记出问题的网元后，将该流程标识为异常流程。

所述判断信令是否失败，进一步包括：如果其中一条信令的名称直接标识信令失败，则将流程标识为异常流程；

如果不能直接通过名称来判断信令是否失败，则需要识别一下该信令是否包含原因码，如果包含原因码，则提取原因码，如果不包含，则继续遍历流程中的信令；

对于提取出来的原因码，判断该原因码是否标识该信令失败，如果标识的是失败，则提取信令的网元名，用以标识流程在该网元处发生失败，并将流程标识为异常流程。

进一步，所述网元名提取的方法是根据信令的方向，如果是发送的，直接提取网元名称，如果是接收的，则利用MD5找到关联的发送信令，再提出网元名称。

所述的异常信令流程辨识方法，进一步包括有重复上述操作，将所有流程异常流程全部识别出来。

与现有的技术相比，本发明可以依据网元上报的单条信令，提取出信令流程，并识别出异常信令流程。将网元间的信令流程识别出来，然后在此基础上，将异常流程提取出来，将极大的提高系统信令分析、辅助定位、解决问题的能力。

通过异常信令流程，能够快速的定位到发生问题的网元以及问题产生的原因，极大地提高排除问题的效率，也为日常的系统维护提供了很大的便利；同时，信令流程作为信令跟踪的基本概念，为用户分析或者用户间交流提供了公共的语言。

附图说明

图1是一个信令流程的示意图。

图2是本发明中提取信令流程的流程图。

图3是本发明中辨识异常信令流程的流程图。

图4是本发明第一实施例的客户端信令流程提取与异常信令流程识别流程图。

图5是本发明第二实施例的客户端查看服务器定时信令分析结果流程图。

具体实施方式

下面结合附图对本发明的具体实施做出详细描述，但是应当理解的是对于本发明的详细描述并不代表实现本发明的所有实现方式。

以附着流程为例，如图1所示，定义一个信令流程。

图中所示，附着流程包括有：

起始信令：

Attach Request

结束信令组：

Attach reject

Modify Bearer Response

因为图1是个正常流程，而Attach reject是异常信令流程的结束信令，在图1中没有，其是出现在异常信令流程中。

中间信令(必有)：

Create Session Request

Create Session Response

Initial Context Setup Request

等等。

中间信令(可有)

Delete Session Request

Delete Session Response

等等。

依据上面的信令流程模型并结合具体的业务，可以定义出若干业务信令流程。

对于抽象信令流程模型，它包含三个重要的组成部分。

起始信令：信令流程的触发信令，也可以说是流程的第一条信令。

结束信令：信令流程的最后一条信令，该条信令标识流程的完结。如图中最下面所示的结束信令1、结束信令2、……、结束信令n，这表示结束信令有多种可能。这是因为流程有可能正常结束，也有可能异常结束(比如流程失败了)，或其他的一些情况，结束信令往往不唯一。

中间信令：除起始、结束信令之外的，在网元间传递和转换的信令。该部分信令的特点是某些信令会根据不同的组网、业务等情况，会条件的出现。鉴于这个特点，该部分信令可以分成两大类：流程必定包含的信令和流程可能包含的信令。

依据上面的信令流程，可以映射得到的信令流程模型。该模型有起始信令、中间信令(必有)、中间信令(可有)、结束信令组。起始信令标识该流程的起始；中间信令(必有)包含该流程中必定包含的信令；中间信令(可有)包含该流程中条件出现的信令；结束信令组，定义了若干条与流程起始信令对应的结束信令(每条结束信令都可能是该流程的结束)。

有了上面定义的业务流程，下面结合图2，讲解一下提取信令流程的主要步骤，如下：

步骤201、遍历采集到的信令数据集合。

步骤202、判断提取出的集合中的一条信令是否能和某个配置的业务信令流程的起始信令相匹配，如果不能，则继续遍历采集到的信令数据集合。

步骤203、如果信令是某个业务流程的起始信令，则找到与起始信令对应的结束信令组。

步骤204、遍历结束信令组，从若干结束信令中提取出一条失败信令，然后从信令集合中当前信令的下一条开始索引结束信令，如果没有索引到结束信令，则继续遍历结束信令，直到遍历结束。

步骤205、如果索引到了结束信令，则依据起始信令编号和结束信令编号将这一闭区间的信令全部提取出来。

步骤206、流程清洗。在流程提取前，会对多个网元上报的信令进行排序，排序主要的依据是单网元信令的上报顺序，以及信令的时间戳，由于网元时间的不一致以及业务的复杂性(比如正在做数据业务，之间来了电话)，都会导致提取的流程中可能会夹杂不是本流程的信令。可以利用之前业务流程中定义的信令(起始、结束信令以及中间信令)对流程进行清洗，即将流程中不在其中的信令移除。

步骤207、将清洗后的信令提取出来，并将起始、结束信令打上标记(标注哪条是起始信令、哪条是结束信令)，构建信令流程。

步骤208、继续遍历采集到的信令数据集合(不是从结束信令开始遍历，而是从起始信令的下一条开始)，直到遍历到最后一条信令，将所有的信令流程都提取出来为止。

在将流程提取出来的基础上，下一步就可以辨识异常信令流程了。结合图3，辨识的步骤如下：

步骤301、遍历提取出来的信令流程。

步骤302、遍历信令流程中包含起始、结束信令区间的信令。

步骤303、如果其中一条信令的名称直接标识信令失败，则将流程标识为异常流程。

步骤304、如果不能直接通过名称来判断信令是否失败，则需要识别一下该信令是否包含原因码，如果包含原因码，则提取原因码，如果不包含，则继续遍历流程中的信令。

步骤305、对于提取出来的原因码，需要判断一下该原因码是否标识该信令失败(因为有些是标识成功的)，如果标识的是失败，则提取信令的网元名(提取的方法是根据信令的方向，如果是发送的，直接提取网元名称，如果是接收的，则利用MD5找到关联的发送信令，再提出网元名称)，用以标识流程在该网元处发生失败，并将流程标识为异常流程。

步骤306、按照步骤3、4、5的方式，遍历该流程中所有的信令。

步骤307、流程遍历结束后，获取该业务流程模型中定义的中间信令(必有)部分的信令。

步骤308、遍历中间信令(必有)部分的信令。

步骤309、如果中间信令(必有)中的一条在信令流程中能够匹配到，则继续遍历，如果匹配不到，则判断该条信令的发送网元类型在信令流程中是否只包含一个该类型被跟踪的网元，如果只有一个，则能确定该网元缺失信令，如果有多个，则只能确定该流程中缺失该条信令，并将流程标识为异常流程。

步骤310、待流程遍历结束后，利用MD5将发送和接收的信令关联起来。

步骤311、在关联的过程中辨识是否存在不能匹配的信令，或称单点信令，如果该信令所对应的源或者目的IP是系统中跟踪网元的IP，则说明流程异常(可能是对端的网元漏报了信令，也可能网元发了，但是信令跟踪系统没有接收到)，标记出问题的网元后，将该流程标识为异常流程。

步骤312、依据步骤2到步骤11，将所有流程异常流程全部识别出来。

通过上述方法，本发明可以依据网元上报的单条信令，提取出信令流程，并识别出异常信令流程。用户可以通过异常信令流程，快速的定位到发生问题的网元以及问题产生的原因，能极大的提高排除问题的效率，也为日常的系统维护提供了很大的便利。

同时，信令流程作为信令跟踪的基本概念，为用户分析或者用户间交流提供了公共的语言。

本发明提供的第一实施例如图4所示，描述客户端直接打开信令文件触发流程提取和异常信令分析的流程。该流程包括以下步骤：

步骤S100、网管系统已经采集各网元上报的信令并汇总为信令文件。

步骤S101、客户端请求直接打开已经生成的信令文件。

步骤S102、系统读取信令文件并触发异常信令识别过程。

步骤S103、进行信令流程提取过程。

步骤S104、根据异常信令索引，标识归属的信令流程为异常流程。

步骤S105、流程提取和识别的结果返回给界面展示单元，由界面展示单元进行进一步的渲染。

步骤S106、渲染结果以及数据返回给界面展示单元进行展示，打开信令文件流程结束。

本发明提供的第二实施例，描述服务器定时进行缓存信令分析，触发流程提取和异常信令识别过程，客户端查看分析结果。该流程包括以下步骤：

步骤S200、网管客户端与服务器之间正常建立连接。

步骤S201、网管客户端创建跟踪任务，信令正常由各网元上报到服务器。

步骤S202、网管服务器缓存信令文件。

步骤S203、网管服务器定时对缓存信令文件进行分析处理。

步骤S204、服务器针对信令文件进行信令流程提取过程。

步骤S205、针对已经识别的信令流程，识别异常信令，标识异常信令流程。

步骤S206、将识别结果存入数据库。

步骤S207、网管客户端请求查看服务器数据。

步骤S208、网管服务器返回分析后的结果返回给客户端。

步骤S209、网管客户端获取返回分析后的结果并进行其他处理和渲染。

步骤S210、渲染结果以及数据返回给界面展示单元进行展示，客户端查看服务器分析后的结果流程结束。

以上仅为本发明的优选实施例，并非因此限制本发明的专利范围，凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本发明的专利保护范围内。

Claims (10)

1.一种异常信令流程辨识方法，其特征在于该方法梳理各业务操作对应的信令流程，进而抽象出信令流程模型，根据信令流程模型提取信令流程，从信令流程中识别出异常信令流程，主要内容包括：

抽象信令流程：包括信令流程的起始信令、结束信令、业务操作名称、包含的子流程；

抽象关键信令：针对信令流程模型中的起始信令、结束信令进行标识定义，用于信令识别；

抽象出信令流程后，对关键信令进行标识定义，然后建立信令流程模型，通过信令流程模型对信令进行识别，从网元上报的信令中提取信令流程；

遍历信令流程中所有的信令；

流程遍历结束后，获取并遍历该信令流程模型中定义的中间信令中必有部分的信令；

如果中间信令必有部分的信令中的一条在信令流程中能够匹配到，则继续遍历，如果匹配不到，则判断该条信令的发送网元类型在信令流程中是否只包含一个该类型被跟踪的网元，如果只有一个，则能确定该网元缺失信令，如果有多个，则只能确定该流程中缺失该条信令，并将流程标识为异常流程；

待流程遍历结束后，利用MD5将发送和接收的信令关联起来；

在关联的过程中辨识是否存在不能匹配的信令，或称单点信令，如果该信令所对应的源或者目的IP是系统中跟踪网元的IP，则说明流程异常，标记出问题的网元后，将该流程标识为异常流程。

2.如权利要求1所述的方法，其特征在于所述信令流程模型，包括：

起始信令：信令流程的触发信令，即流程的第一条信令；

中间信令：除起始、结束信令之外的，在网元间传递和转换的信令，该部分信令的特点是某些信令会根据不同的组网、业务情况，会条件的出现；

结束信令：信令流程的最后一条信令，该条信令标识流程的完结。

3.如权利要求1所述的方法，其特征在于所述方法，在关键信令和信令流程模型的基础上，依据网元上报的信令，进行信令流程提取；所述信令流程提取是逐条遍历信令文件中的所有信令，匹配出能和配置的信令流程模型匹配的起始信令，然后逐条遍历出能和配置的信令流程模型匹配的结束信令。

4.如权利要求1所述的方法，其特征在于，对于代表业务失败的信令通过信令事件名称或者信令的原因码进行标识，依据3GPP规范整理业务操作可能的失败事件名称以及失败原因码的取值列表，遍历并解析信令文件，依据整理的失败列表识别异常信令，在信令流程提取出来的基础上，将包含异常信令的信令流程进行标识；对于单点信令，使用虚线进行标识。

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

遍历采集到的信令数据集合；

判断提取出的集合中的一条信令是否能和某个配置的业务信令流程的起始信令相匹配，如果不能，则继续遍历采集到的信令数据集合；

如果信令是某个信令流程的起始信令，则找到与起始信令对应的结束信令组；

遍历结束信令组，从若干结束信令中提取出一条失败信令，然后从信令集合中当前信令的下一条开始索引结束信令，如果没有索引到结束信令，则继续遍历结束信令，直到遍历结束；

如果索引到了结束信令，则依据起始信令编号和结束信令编号将这一闭区间的信令全部提取出来；

流程清洗；利用之前信令流程中定义的信令对流程进行清洗，将流程中不在其中的信令移除；

将清洗后的信令提取出来，并将起始、结束信令打上标记，构建信令流程；

继续遍历采集到的信令数据集合，直到遍历到最后一条信令，将所有的信令流程都提取出来为止。

6.如权利要求5所述的方法，其特征在于在流程清洗前，先对多个网元上报的信令进行排序，排序主要的依据是单网元信令的上报顺序，以及信令的时间戳，将流程中不是本流程的信令移除。

7.如权利要求1所述的方法，其特征在于,异常信令流程辨识方法还包括：

遍历提取出的信令流程；

遍历信令流程中包含起始、结束信令区间的信令；

通过一条信令判断信令是否失败，将流程标识为异常流程。

8.如权利要求7所述的方法，其特征在于判断信令是否失败，进一步包括：如果其中一条信令的名称直接标识信令失败，则将流程标识为异常流程；

如果不能直接通过名称来判断信令是否失败，则需要识别一下该信令是否包含原因码，如果包含原因码，则提取原因码，如果不包含，则继续遍历流程中的信令；

对于提取出来的原因码，判断该原因码是否标识该信令失败，如果标识的是失败，则提取信令的网元名，用以标识流程在该网元处发生失败，并将流程标识为异常流程。

9.如权利要求8所述的方法，其特征在于所述网元名提取的方法是根据信令的方向，如果是发送的，直接提取网元名称，如果是接收的，则利用MD5找到关联的发送信令，再提出网元名称。

10.如权利要求7所述的方法，其特征在于所述的异常信令流程辨识方法，进一步包括有重复上述操作，将所有流程异常流程全部识别出来。

Images