网络故障定位方法及设备与流程

文档序号:17817268发布日期:2019-06-05 21:53
网络故障定位方法及设备与流程

本发明实施例涉及通信技术领域,尤其涉及一种网络故障定位方法及设备。



背景技术:

当通讯网络发生故障时,需要检测出网络故障的来源并对定位的故障进行解决。目前,网络故障导致通讯业务异常时,业务网元可以通过用户投诉获取该用户的用户标识,例如多媒体公共标识(IP multimedia public identity,IMPU)、多媒体私有标识(IP multimedia private identity,IMPI)和国际移动用户识别码(international mobile subscriber identification number,IMSI)等,并创建该用户标识对应的用户跟踪,通过用户跟踪获取该用户标识对应的用户跟踪信息。分析该用户跟踪信息可以确认和解决该网络故障。

然而,在网络发生故障后,当用户未进行用户投诉时,业务网元无法获取故障用户的用户标识。网络故障会导致网络中某个或某些业务参数会发生变化。例如,初始注册成功率下降,语音业务连续性(single radio voice call continuity,SRVCC)下降,切换成功率下降,呼叫建立时延增加,掉话率上升等等。可以通过话务统计、SEQ、呼叫日志(CHR,call history record)分析,得到某个协议接口特定的原因值,某个特定的全局失败原因值,某个特定的CHR第一拆线点,来确定网络故障可能的类型。然而,同一个故障类型对应的故障场景繁多,通过上述业务参数来确认的故障类型往往很难确定具体的故障场景,很难进行故障的定位和解决,从而降低了网络故障的定位效率。



技术实现要素:

本申请实施例提供一种网络故障定位方法及设备。可以提高网络故障的定位效率。

第一方面,本申请实施例提供了一种网络故障定位方法,包括:业务网元接收第一用户发送的业务消息,所述业务消息携带所述业务消息的第一参数;所述第一参数包括以下至少一项:业务类型、消息类型、用户类型、接口原因值、全局失败原因值和业务消息字段取值;所述业务网元检测所述业务消息的第一参数是否满足跟踪条件;所述跟踪条件用于指示第一故障发生时所述第一参数的取值;如果所述业务消息的第一参数满足所述跟踪条件,则所述业务网元为所述第一用户设置跟踪标识,所述跟踪标识用于指示对所述第一用户进行信令跟踪以获取所述第一用户的信令流程,所述第一用户的信令流程用于进行网络故障定位。将第一故障发生时的故障参数取值设置为跟踪条件,通过该跟踪条件过滤出满足该跟踪条件的业务消息的用户,并对该用户进行信令流程跟踪,来进行网络故障定位,在没有用户投诉的场景下,也可以通过故障条件过滤出需要进行信令流程跟踪的用户,通过对用户进行信令流程跟踪来进行网络故障定位,可以快速确认出故障场景,从而提高了网络故障的定位效率。

在一个实施例中,如果所述业务消息的第一参数满足所述跟踪条件,所述方法还包括:所述业务网元检测已跟踪的用户数是否小于最大跟踪用户数;在所述已跟踪的用户数小于所述最大跟踪用户数的情况下,所述业务网元为所述第一用户设置跟踪标识。为业务网元设定最大跟踪用户数,该最大跟踪用户数是业务网元能够同时进行信令流程跟踪的最大数量,更加符合业务网元的处理能力,减少超出业务网元处理能力引起堵塞的情况。

在一个实施例中,所述业务网元为所述第一用户设置跟踪标识之后,在对所述第一用户进行信令跟踪的时长大于预设时长的情况下,所述业务网元取消对所述第一用户进行的信令跟踪;所述业务网元检测接收到的第二用户发送的业务消息携带的业务消息的第一参数是否满足所述跟踪条件;如果所述第二用户发送的业务消息携带的业务消息的第一参数满足所述跟踪条件,则所述业务网元为所述第二用户设置跟踪标识。对跟踪的用户进行跟踪时长进行限定,可以收集更多的符合网络故障跟踪条件的用户的信令流程,增加了网络故障分析的样本,可以提高网络故障的定位效率。

在一个实施例中,所述业务网元为所述第一用户设置跟踪标识之后,在对所述第一用户进行信令跟踪的时长大于预设时长的情况下,所述业务网元检测接收到的第二用户发送的业务消息携带的业务消息的第一参数是否满足所述跟踪条件;如果所述第二用户发送的业务消息携带的业务消息的第一参数满足所述跟踪条件,则所述业务网元取消对所述第一用户进行的信令跟踪,为所述第二用户设置跟踪标识。在业务网元未检测到满足跟踪条件的新的用户的情况下,仍然持续对达到预设跟踪时长的用户进行跟踪,直到找到新的满足跟踪条件的第二用户,才停止对第一用户的跟踪,可以在一定时长内获取更多的符合网络故障跟踪条件的用户的信令流程,可以提高网络故障的定位效率。

在一个实施例中,所述业务网元为所述第一用户设置跟踪标识之后,所述业务网元将所述第一用户的信令流程发送给终端,所述第一用户的信令流程用于所述终端根据所述第一用户的信令流程进行网络故障定位。

在一个实施例中,所述业务网元接收第一用户发送的业务消息之前,所述业务网元接收网络设备发送的携带跟踪条件的跟踪任务信息;所述跟踪任务信息是所述终端发送给所述网络设备的。

第二方面,本申请实施例提供了另一种网络故障定位方法,包括:终端向网络设备发送携带跟踪条件的跟踪任务信息;所述跟踪条件用于业务网元检测业务消息的第一参数是否满足所述跟踪条件,当所述业务消息的第一参数满足所述跟踪条件时,为第一用户设置跟踪标识;所述第一参数包括以下至少一项:业务类型、消息类型、用户类型、接口原因值和业务消息字段取值;所述跟踪条件指示第一故障发生时所述第一参数的取值;所述业务消息的第一参数是所述业务网元接收到所述第一用户发送的业务消息中携带的;所述跟踪标识用于指示对所述第一用户进行信令跟踪以获取所述第一用户的信令流程,所述第一用户的信令流程用于进行网络故障定位。将第一故障发生时的故障参数取值设置为跟踪条件,通过该跟踪条件过滤出满足该跟踪条件的业务消息的用户,并对该用户进行信令流程跟踪,来进行网络故障定位,在没有用户投诉的场景下,也可以通过故障条件过滤出需要进行信令流程跟踪的用户,通过对用户进行信令流程跟踪来进行网络故障定位,可以快速确认出故障场景,从而提高了网络故障的定位效率。

在一个实施例中,所述终端接收所述网络设备发送的携带所述第一用户的信令流程的消息;所述携带所述第一用户的信令流程的消息是所述业务网元发送给所述网络设备的。

第三方面,本申请实施例提供了又一种网络故障定位方法,包括:网络设备在接收到携带跟踪条件的跟踪任务信息的情况下,将所述跟踪任务信息发送给业务网元;所述跟踪条件用于业务网元检测业务消息的第一参数是否满足所述跟踪条件,当所述业务消息的第一参数满足所述跟踪条件时,为第一用户设置跟踪标识;所述第一参数包括以下至少一项:业务类型、消息类型、用户类型、接口原因值和业务消息字段取值;所述跟踪条件指示第一故障发生时所述第一参数的取值;所述业务消息的第一参数是所述业务网元接收到所述第一用户发送的业务消息中携带的;所述跟踪标识用于指示对所述第一用户进行信令跟踪以获取所述第一用户的信令流程,所述第一用户的信令流程用于进行网络故障定位。将第一故障发生时的故障参数取值设置为跟踪条件,通过该跟踪条件过滤出满足该跟踪条件的业务消息的用户,并对该用户进行信令流程跟踪,来进行网络故障定位,在没有用户投诉的场景下,也可以通过故障条件过滤出需要进行信令流程跟踪的用户,通过对用户进行信令流程跟踪来进行网络故障定位,可以快速确认出故障场景,从而提高了网络故障的定位效率。

在一个实施例中,所述述网络设备接收所述业务网元发送的携带所述第一用户的信令流程的消息;所述网络设备将携带所述第一用户的信令流程的消息发送给终端。

第四方面,本申请实施例提供了一种业务网元,该业务网元包括用于执行第一方面或第一方面的任一种可能实现方式所提供的网络故障定位方法的模块或单元。

第五方面,本申请实施例提供了一种终端,该终端包括用于执行第二方面或第二方面的任一种可能实现方式所提供的网络故障定位方法的模块或单元。

第六方面,本申请实施例提供了一种网络设备,该网络设备包括用于执行第三方面或第三方面的任一种可能实现方式所提供的网络故障定位方法的模块或单元。

第七方面,本申请实施例提供了另一种业务网元,包括:处理器,存储器,收发器和总线;处理器、收发器、存储器通过总线相互通信;收发器,用于接收和发送数据;存储器,用于存储指令;处理器,用于调用存储器中的指令,执行第一方面或第一方面的任一种可能实现方式所提供的网络故障定位方法。

第八方面,本申请实施例提供了另一种终端,包括:处理器,存储器,收发器和总线;处理器、收发器、存储器通过总线相互通信;收发器,用于接收和发送数据;存储器,用于存储指令;处理器,用于调用存储器中的指令,执行第二方面或第二方面的任一种可能实现方式所提供的网络故障定位方法。

第九方面,本申请实施例提供了另一种网络设备,包括:处理器,存储器,收发器和总线;处理器、收发器、存储器通过总线相互通信;收发器,用于接收和发送数据;存储器,用于存储指令;处理器,用于调用存储器中的指令,执行第三方面或第三方面的任一种可能实现方式所提供的网络故障定位方法。

第十方面,本申请实施例提供了一种计算机可读存储介质,该存储介质包括指令,当该指令在业务网元上运行时,使得业务网元执行第一方面或第一方面的任一种可能实现方式所提供的网络故障定位方法。

第十一方面,本申请实施例提供了一种计算机可读存储介质,该存储介质包括指令,当该指令在终端上运行时,使得终端执行第二方面或第二方面的任一种可能实现方式所提供的网络故障定位方法。

第十二方面,本申请实施例提供了一种计算机可读存储介质,该存储介质包括指令,当该指令在网络设备上运行时,使得网络设备执行第三方面或第三方面的任一种可能实现方式所提供的网络故障定位方法。

第十三方面,本申请实施例提供了一种计算机程序,该计算机程序包括指令,当该指令在业务网元上运行时,使得业务网元执行第一方面或第一方面的任一种可能实现方式所提供的网络故障定位方法。

第十四方面,本申请实施例提供了一种计算机程序,该计算机程序包括指令,当该指令在终端上运行时,使得终端执行第二方面或第二方面的任一种可能实现方式所提供的网络故障定位方法。

第十五方面,本申请实施例提供了一种计算机程序,该计算机程序包括指令,当该指令在网络设备上运行时,使得网络设备执行第三方面或第三方面的任一种可能实现方式所提供的网络故障定位方法。

第十六方面,本申请实施例提供了一种业务网元的芯片产品,以执行第一方面或第一方面的任意可能的实现方式中的方法。

第十七方面,本申请实施例提供了一种终端的芯片产品,以执行第二方面或第二方面的任意可能的实现方式中的方法。

第十八方面,本申请实施例提供了一种网络设备的芯片产品,以执行第三方面或第三方面的任意可能的实现方式中的方法。

本申请实施例中,将第一故障发生时的故障参数取值设置为跟踪条件,通过该跟踪条件过滤出满足该跟踪条件的业务消息的用户,并对该用户进行信令流程跟踪,来进行网络故障定位,在没有用户投诉的场景下,也可以通过故障条件过滤出需要进行信令流程跟踪的用户,通过对用户进行信令流程跟踪来进行网络故障定位,可以快速确认出故障场景,从而提高了网络故障的定位效率。

附图说明

为了更清楚地说明本发明实施例或背景技术中的技术方案,下面将对本发明实施例或背景技术中所需要使用的附图进行说明。

图1是本申请实施例提供的一种网络故障定位系统架构示意图;

图2是本申请实施例提供的一种本地维护终端10的结构示意图;

图3是本申请实施例提供的一种网络设备20的结构示意图;

图4是本申请实施例提供的一种网络设备30的结构示意图;

图5是本申请实施例提供的一种网络故障定位方法的流程示意图;

图6是本申请实施例提供的一种业务网元30的结构示意图;

图7是本申请实施例提供的另一种本地维护终端10的结构示意图;

图8是本申请实施例提供的另一种网络设备20的结构示意图。

具体实施方式

下面结合本发明实施例中的附图对本发明实施例进行描述。本申请的实施方式部分使用的术语仅用于对本申请的具体实施例进行解释,而非旨在限定本申请。

本申请实施例公开了一种网络故障定位方法及设备,用于提高网络故障的定位效率。以下分别进行详细说明。

请参见图1,图1是本申请实施例提供的一种网络故障定位系统架构示意图。如图1所示,该网络故障定位系统100包括:本地维护终端10(local maintainance terminal,LMT)、操作和维护设备20(operation and maintenance unit,OMU)和业务网元30组成。

本地维护终端10,也可以称为OMU客户端,LMT提供图形化用户界面,实现跟踪任务的输入、命令执行结果的显示、告警显示、消息跟踪、性能监测和设备维护、日志管理等功能。

操作和维护设备20,充当LMT和业务网元30的连接桥梁。OMU通过维护网口连接到LMT。OMU和LMT可以看作是客户端/服务器(clint/server,C/S)架构。OMU通过有线连接与业务网元连接。一个OMU可以同时管理多个业务网元30,并对外提供统一的操作维护管理接口。

操作和维护设备20用于支持告警、跟踪、设备和日志等的管理,并可以发送相关信息给OMU客户端。具体地,告警管理是指OMU监测设备运行过程中产生的各种软硬件故障,监测到故障信息后将故障信息发送给LMT,以提醒维护人员解决。跟踪管理是指OMU可以存储并向业务网元30分发跟踪任务信息,并接收业务网元30发送的跟踪得到的信令流程,将该信令流程发送给LMT。跟踪管理还包括管理和维护进行网络故障定位时的配置数据和告警信息。设备管理是指OMU对一个或多个主机的集中管理和监控,可以包括增加、删除、修改主机的功能。日志管理是指OMU提供保存和查看对设备的所有操作日志的功能。

业务网元30,用于接收到OMU发送的跟踪任务信息,并向OMU返回指示跟踪任务创建成功的信息。业务网元还用于,在业务触发的情况下,根据接收到的信令消息携带的用户标识查询跟踪任务,如果该用户标识存在跟踪任务,即向OMU上报该用户标识对应的业务信令流程。业务网元30还可以用于接收携带跟踪条件的跟踪任务,并检测用户的业务消息是否满足跟踪条件。在检测到用户的业务消息满足跟踪条件的情况下,为该用户设置跟踪标识,用于获取该用户的信令流程。

业务网元30可以是一种网络设备,可以为基站,基站可以用于与一个或多个终端进行通信,也可以用于与一个或多个具有部分终端功能的基站进行通信(比如宏基站与微基站,如接入点之间的通信)。业务网元也可以是用户数据中心(subscriber data center,SDC),业务网元还可以是归属签约用户服务器(home subscriber server,HSS)。业务网元还可以是其他的网络实体,本申请对此不作限定。

可以理解的是,本地维护终端10、操作和维护设备20和业务网元30的功能可以根据实际需求增加或者减少,本申请实施例对此不作限定。

需要说明的,图1示出的网络故障定位系统100仅仅是为了更加清楚的说明本申请的技术方案,并不构成对本申请的限定,本领域普通技术人员可知,随着网络架构的演变和新业务场景的出现,本申请提供的技术方案对于类似的技术问题,同样适用。

请参见图2,图2是本申请实施例提供的一种本地维护终端10的结构示意图。如图2所示,该本地维护终端10可包括:一个或多个终端处理器101、存储器102和通信接口103。这些部件可通过总线104或者其他方式连接,图2以通过总线连接为例。其中:

通信接口103可用于本地维护终端10与其他通信设备,例如网络设备,进行通信。具体的,所述网络设备可以是图3所示的操作和维护设备10。具体的,通信接口103可以是有线通信接口,本地维护终端10可以配置有有线的通信接口103,例如局域接入网(Local Access Network,LAN)接口。

存储器102与终端处理器101耦合,用于存储各种软件程序和/或多组指令。具体的,存储器102可包括高速随机存取的存储器,并且也可包括非易失性存储器,例如一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。存储器102还可以存储网络通信程序,该网络通信程序可用于与一个或多个附加设备,一个或多个终端设备,一个或多个网络设备进行通信。在本申请的一些实施例中,存储器102可用于存储本申请的一个或多个实施例提供的网络故障定位方法在本地维护终端10侧的实现程序。关于本申请的一个或多个实施例提供的网络故障定位方法的实现,请参考后续实施例。

终端处理器101可用于读取和执行计算机可读指令。具体的,终端处理器101可用于调用存储于存储器112中的程序,例如本申请的一个或多个实施例提供的网络故障定位方法在本地维护终端10侧的实现程序,并执行该程序包含的指令。

可以理解的,本地维护终端10可以是图1示出的网络故障定位系统100中的本地维护终端10,可实施为移动设备,移动台(mobile station),移动单元(mobile unit),无线单元,远程单元,用户代理,移动客户端等等。

需要说明的,图2所示的本地维护终端10仅仅是本申请实施例的一种实现方式,实际应用中,本地维护终端10还可以包括更多或更少的部件,这里不作限制。

请参见图3,图3是本申请实施例提供的一种网络设备20的结构示意图。如图2所示,该网络设备20可以是图1所描述的系统架构中的操作和维护设备20,该网络设备20可包括:一个或多个网络设备处理器201、存储器202和通信接口203。这些部件可通过总线204或者其他式连接,图3以通过总线连接为例。其中:

通信接口203可用于网络设备20与其他通信设备,例如终端设备或其他设备,进行通信。具体的,所述终端设备可以是图2所示的本地维护终端10,所述其他设备可以是图4所示的业务网元30。具体的,通信接口203可以是有线接口,网络设备20可以配置有有线的通信接口203来支持有线通信,例如一个网络设备200与其他设备之间的回程链接可以是有线通信连接。存储器202与网络设备处理器201耦合,用于存储各种软件程序和/或多组指令。

具体的,存储器202可包括高速随机存取的存储器,并且也可包括非易失性存储器,例如一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。存储器202还可以存储网络通信程序,该网络通信程序可用于与一个或多个附加设备,一个或多个终端设备,一个或多个网络设备进行通信。

本申请实施例中,网络设备处理器201可用于读取和执行计算机可读指令。具体的,网络设备处理器201可用于调用存储于存储器202中的程序,例如本申请的一个或多个实施例提供的网络故障定位方法在网络设备20侧的实现程序,并执行该程序包含的指令。需要说明的,图2所示的本地维护终端10和图3所示的网络设备20可以是在一个网络实体上,也可以是在不同的网络实体上,本申请实施例对此不作限定。图3所示的网络设备20仅仅是本申请实施例的一种实现方式,实际应用中,网络设备20还可以包括更多或更少的部件,这里不作限制。

请参见图4,图4是本申请实施例提供的一种网络设备30的结构示意图。如图4所示,该网络设备30可以是图1所描述的系统架构中的操作和业务网元30,该网络设备30可包括:一个或多个业务处理器301、存储器302和通信接口303,这些部件可通过总线304或者其他式连接,图4以通过总线连接为例。其中:

通信接口303可用于网络设备30与其他通信设备,例如网络设备,进行通信。具体的,所述网络设备30可以与图3所示的网络设备20进行通信。具体的,通信接口303可以是有线通信接口,例如一个网络设备30与其他网络设备之间的回程链接可以是有线通信连接。存储器302与业务处理器301耦合,用于存储各种软件程序和/或多组指令。具体的,存储器302可包括高速随机存取的存储器,并且也可包括非易失性存储器,例如一个或多个磁盘存储设备、闪存设备或其他非易失性固态存储设备。存储器302还可以存储网络通信程序,该网络通信程序可用于与一个或多个附加设备,一个或多个终端设备,一个或多个网络设备进行通信。本申请实施例中,业务处理器301可用于读取和执行计算机可读指令。具体的,业务处理器301可用于调用存储于存储器302中的程序,例如本申请的一个或多个实施例提供的网络故障定位方法在网络设备30侧的实现程序,并执行该程序包含的指令。

可以理解的,网络设备30可以是图1示出的网络故障定位系统100中的业务网元30,可实施为基站收发台,无线收发器,一个基本服务集(BSS),一个扩展服务集(ESS),NodeB,eNodeB,接入点或TRP等等。

需要说明的,图4所示的网络设备30仅仅是本申请实施例的一种实现方式,实际应用中,网络设备30还可以包括更多或更少的部件,这里不作限制。

需要进行说明的,本地维护终端10是依据功能命名的,不对设备的名称做任何限制,本地维护终端10可以有其他的名称。网络设备20和网络设备30可以是独立的设备,也可以是网络设备中的一个或多个功能。网络设备20和网络设备30还可以是同一设备实现。

如果网络发生故障,会导致网络业务出现异常,从而引起客户投诉。可以通过客户投诉获取投诉的客户的用户标识,LMT可以创建投诉客户用户标识的用户跟踪,并将该用户跟踪任务经由OMU分发给业务网元,业务网元执行对投诉客户的信令流程的跟踪,并将得到的投诉客户的信令流程经由OMU发送给LMT。运维人员可以通过分析该投诉用户的信令流程来确认和解决网络故障。然而,在客户未投诉导致没有跟踪的目标客户的情况下,由于网络故障会引起业务指标如初始注册成功率发生变化,可以通过分析工具,例如话务统计、SEQ或者CHR来检测业务执行过程的参数值。运维人员可以根据这些参数值的异常来确定网络故障的类型。然而同一种故障类型对应多种具体的故障场景,很难根据网络故障的类型确定具体的故障原因,不利于故障的定位和解决,从而降低了网络故障的定位效率。

基于前述网络故障定位系统100、本地维护终端10、网络设备20以及网络设备30分别对应的实施例,本申请实施例提供了一种网络故障定位方法。

本申请的主要发明原理可包括:预先设置跟踪条件,将有可能与第一故障相关联的故障参数设置为跟踪条件,业务网元根据该跟踪条件检测业务消息是否满足该跟踪条件,如果满足该跟踪条件,即为该业务消息对应的第一用户设置跟踪标识,来对该第一用户进行跟踪以获取第一用户的信令流程。该第一用户的信令流程用于进行网络故障定位。

举例来说,如果某一故障会引起初始注册成功率下降,则可以确定跟踪条件为:业务类型等于会话类。当业务网元检测到某一用户发送的业务消息满足业务类型等于会话类的跟踪条件,即该业务消息为会话类的业务消息,则业务网元为该第一用户设置跟踪标识,对该第一用户进行信令流程跟踪,并根据第一用户的信令流程进行网络故障定位。

再例如,如果某一故障也会引起推送通知应答(push notification answer,PNA)/推送通知请求(push notification request,PNR)消息增加,则可以确定跟踪条件为:消息类型等于PNA/PNR。当业务网元检测到某一用户发送的业务消息满足消息类型等于PNA/PNR的跟踪条件,即该业务消息是PNA/PNR,则业务网元为该第一用户设置跟踪标识,对该第一用户进行信令流程跟踪,并根据第一用户的信令流程进行网络故障定位。

将第一故障发生时的故障参数取值设置为跟踪条件,通过该跟踪条件过滤出满足该跟踪条件的业务消息的用户,并对该用户进行信令流程跟踪,来进行网络故障定位,该故障跟踪方法能够基于设置的跟踪条件,随机性的选择满足跟踪条件的任何用户并上报该用户跟踪。支持基于业务类型、消息类型和原因值进行用户的定位。还支持基于某些消息的头域取值进行用户的定位,通过对用户进行信令流程跟踪来进行网络故障定位,可以快速确认出故障场景,从而提高了网络故障的定位效率。

需要说明的,上述示例仅仅用于解释本申请的发明原理,不应构成限定。

为了便于理解本申请实施例,对本申请实施例涉及的一些概念或术语进行解释。

(1)跟踪任务

跟踪任务可以是运维人员通过LMT客户端创建的,跟踪任务创建完成后,即发送给OMU。在LMT客户端创建跟踪任务是为了通过OMU分发给业务网元,来使业务网元根据该跟踪任务获取需要跟踪的用户,并对需要跟踪的用户进行信令流程跟踪,最终根据用户的信令流程来对网络故障进行定位和解决。

(2)跟踪条件

跟踪条件用于捕获需要跟踪的用户。跟踪条件可以是携带在LMT客户端发送的跟踪任务中下发给OMU,并通过OMU广播给业务网元的。

本申请实施例中,跟踪条件可以是根据网络故障发生后参数满足的条件确定的。跟踪条件也可以是根据网络运维知识通过人工或者分析工具来确定的。跟踪条件还可以设置为空。以下针对跟踪条件的设置依据分别进行介绍。

跟踪条件可以是网络故障发生后,维护人员通过工具(例如SmartCare、CHR、SEQ)或者性能统计中获取与网络故障有关的关键参数,将此时业务消息满足的参数条件设置为跟踪条件。跟踪条件也可以是通过人工或者分析工具来确定的。分析工具例如可以是SEQ、CHR和SessionInsight中的一种或几种,还可以是其他的网络故障分析工具,本申请实施例对此不作限制。可以通过上述分析工具分析得到以下一项或者多项:某个网络故障产生可能的场景、某个网络故障发生时某个协议接口的原因值,某个网络故障发生时某个全局失败原因值、某个网络故障发生时某个自定义接口的原因值、某个网络故障发生时某个或某些消息某些字段的取值等信息。并将以上一项或者多项设置为跟踪条件。通过该跟踪条件来捕获该某个网络故障影响的用户以及携带该用户对应信令流程的跟踪消息,辅助运维人员对网络故障进行分析、解决。其中,协议接口的原因值和自定义接口的原因值可以称为接口原因值。

跟踪条件还可以是空,在跟踪条件是空的情况下,业务网元可以从处理的用户中选择一个或多个用户作为跟踪用户,为这些用户设置跟踪标识。

跟踪条件可以是第一网络故障发生时第一参数满足的取值。其中,第一网络故障可以是任一网络故障,第一参数可以包含上述的接口原因值、全局失败原因值和业务消息字段取值中的一个或者多个,也可以包含业务类型、消息类型。下面对业务类型、消息类型、接口原因值、全局失败原因值和业务消息字段取值分别进行介绍。

表一一种第一参数分类的示例

请参阅表一,表一是一种第一参数分类的示例。如表一所示,业务类型可以是根据会话初始协议(session initiation protocol,SIP)协议定义来分类或者根据特色业务分类。业务类型可以包括会话类、非会话类、UT业务和IP-SMS(internet protocol support of short message service)。消息类型可以根据各个业务涉及的请求响应消息以及各业务类型涉及的相关接口进行分类,可以包括请求消息、响应消息和接口类消息等。请求消息是客户端为了激活特定操作而发给服务器的消息,例如可以是INVITE、ACK、BYE、CANCEL、REGISTER、OPTIONS等,响应消息用于对请求消息进行响应,指示呼叫成功或失败状态。不同类型的响应消息由状态码来区分,状态码的第一位定义响应类型,另两位用于进一步对响应进行详细说明。响应消息例如可以是1xx/2xx/3xx/4xx/5xx/6xx等。如表一所示,接口原因值可以包括SIP协议原因值、Q850协议原因值和CHR拆线原因值等。全局失败原因值可以包括SH失败操作指示、RO失败操作指示和RF失败操作指示等。业务消息字段取值可以根据各个接口的标准协议定义的每个消息的字段定义和取值的含义等。如表一所示,用户类型可以是根据用户级别进行分类,例如VIP用户和普通用户。再例如,一星级用户、二星级用户……等,还可以是其他的分类方法,本申请对此不作限定。

可以理解的是,跟踪条件的设定可以是针对第一参数(业务类型、消息类型、用户类型、接口原因值、全局失败原因值和业务消息字段取值)中的一种或多种。例如,跟踪条件为:业务类型为UT业务消息,消息类型为请求消息,原因值为SIP协议某一原因值N。另外,对于一种跟踪条件,跟踪条件中参数的取值可以是一个,也可以是多个。例如,跟踪条件为:业务类型为会话类消息和UT业务消息,消息类型为响应消息中状态码在500~503的响应消息。

需要说明的,上述跟踪条件和第一参数分类的示例仅仅用于解释本申请的发明原理,不应构成限定。跟踪条件的设定和第一参数的选择也可以通过其他类似地标准进行,本申请实施例对此不作限定。

基于上述主要发明原理,下面说明本申请实施例提供的网络故障定位方法的具体流程。请参阅图5,图5是本申请实施例提供的一种网络故障定位方法的流程示意图,如图5所示,该网络故障定位方法包括但不限于以下步骤。

S101、LMT向OMU发送携带跟踪条件的跟踪任务信息。

S102、OMU向业务网元发送携带跟踪条件的跟踪任务信息。

其中,OMU接收到LMT的跟踪任务信息之后,OMU对跟踪任务信息进行存储,并将跟踪任务信息分发给业务网元,可以是以广播的形式发送给各个业务网元的。

业务网元可以管理和存储多个跟踪任务信息和跟踪条件。业务网元可以在自身存储模块中存储跟踪条件中的消息类型、接口原因值、全局失败原因值和业务消息字段取值等取值信息,以及各个条件之间的组合关系。例如“与”表示需同时满足多个匹配条件。“或”表示只需满足多个匹配条件中的一个。业务网元还可以在自身存储模块中存储条件运算符,如大于、小于、介于、不等于等等,业务网元自身存储模块通过保存这些信息,来支持网元的跟踪功能。

S103、业务网元接收第一用户发送的业务消息。

其中,业务消息可以携带业务消息的第一参数;第一参数包括以下至少一项:业务类型、消息类型、接口原因值、全局失败原因值和业务消息字段取值。第一用户可以是业务网元接收到的任一消息所属的用户。

S104、业务网元检测业务消息的第一参数是否满足跟踪条件。如果业务消息的第一参数满足跟踪条件则执行步骤S105。

其中,跟踪条件用于指示第一故障发生时第一参数的取值;第一故障可以是任一故障。

S105、如果业务消息的第一参数满足跟踪条件,则业务网元为第一用户设置跟踪标识。

其中,业务消息的第一参数满足跟踪条件可以理解为,业务消息的第一参数的参数范围包含在跟踪条件的中第一参数的取值内,则表明业务消息的第一参数满足跟踪条件。跟踪标识用于指示对第一用户进行信令跟踪以获取第一用户的信令流程。

如果跟踪条件为空,业务网元在处理各个接口的业务消息过程中,不需要提取业务消息的第一参数,而可以由业务网元随机选择处理的业务消息对应的用户,为该用户设置跟踪标识。

在为用户设置跟踪标识后,业务网元后续处理该用户相关的业务消息时,就可以获取该用户后续在通信过程中的交互消息。如果该用户之前执行某一信令流程时发生了第一故障,该用户重新执行发生第一故障的信令流程,通过该用户的跟踪标识对该用户进行信令流程跟踪,业务网元就可以获知该用户本次执行信令流程的情况,并将该信令流程上报给LMT,操作维护人员可根据网元上报的信令流程对网络故障进行定位。

S106、业务网元向OMU发送第一用户的信令流程,OMU向LMT发送第一用户的信令流程。

本申请实施例中,为获取更多网络故障相关的信息,业务网元可以为满足跟踪条件的多个用户设置跟踪标识,来同时对多个用户进行信令流程跟踪。由于业务网元的处理能力的限制,可以限定同时进行信令流程跟踪的最大跟踪用户数。根据最大跟踪用户数来确定对哪些用户进行跟踪可以是业务网元内部进行裁决的。业务网元裁决的策略可以至少包含以下一项:先到先得、根据业务类型优先级、根据消息类型优先级和根据用户类型优先级等等。以下分别进行说明。

业务网元裁决对哪些用户进行跟踪的策略可以是先到先得。也就是说,业务网元设定最大跟踪用户数,业务网元同时进行信令流程跟踪的用户数量不能超过该最大跟踪用户数。业务网元检测到业务消息的第一参数满足跟踪条件后,业务网元检测已跟踪的用户数是否小于最大跟踪用户数;在已跟踪的用户数小于最大跟踪用户数的情况下,业务网元可以为第一用户设置跟踪标识来对第一用户进行信令流程跟踪。这里的已跟踪用户数即是当前业务网元进行跟踪的用户数。

业务网元裁决对哪些用户进行跟踪的策略也可以是根据业务类型优先级。业务网元可以预存不同业务类型以及不同业务类型对应的优先级。业务网元检测到业务消息的第一参数满足跟踪条件,且已跟踪的用户数是否小于最大跟踪用户数后,业务网元可以检测第一用户的业务消息的业务类型是否达到预设优先级。如果第一用户的业务消息的业务类型达到预设优先级,业务网元可以为第一用户设置跟踪标识来对第一用户进行信令流程跟踪。另外对于不同的已跟踪的用户数,业务网元可以设置不同的预设优先级。可以是已跟踪用户数越少,预设优先级越低,已跟踪用户数越多,预设优先级越高。

业务网元裁决对哪些用户进行跟踪的策略还可以是根据消息类型优先级。业务网元可以预存不同消息类型以及不同消息类型对应的优先级。业务网元检测到业务消息的第一参数满足跟踪条件,且已跟踪的用户数是否小于最大跟踪用户数后,业务网元可以检测第一用户的业务消息的消息类型是否达到预设优先级。如果第一用户的业务消息的消息类型达到预设优先级,业务网元可以为第一用户设置跟踪标识来对第一用户进行信令流程跟踪。另外对于不同的已跟踪的用户数,业务网元可以设置不同的预设优先级。可以是已跟踪用户数越少,预设优先级越低,已跟踪用户数越多,预设优先级越高。

业务网元裁决对哪些用户进行跟踪的策略还可以是根据用户类型优先级。业务网元可以预存不同用户类型以及不同用户类型对应的优先级。业务网元检测到业务消息的第一参数满足跟踪条件,且已跟踪的用户数是否小于最大跟踪用户数后,业务网元可以检测第一用户的用户类型是否达到预设优先级。如果第一用户的用户类型达到预设优先级,业务网元可以为第一用户设置跟踪标识来对第一用户进行信令流程跟踪。另外对于不同的已跟踪的用户数,业务网元可以设置不同的预设优先级。可以是已跟踪用户数越少,预设优先级越低,已跟踪用户数越多,预设优先级越高。这里的用户类型可以是用户级别,例如普通用户和VIP用户等等。

需要说明的,上述业务网元裁决策略的示例仅仅用于解释本申请实施例,不应构成限定。业务网元裁决的策略也可以根据需求细化具体策略,还可以是以上示例策略中多个的结合,本申请实施例对此不作限定。

一种情况下,业务网元为所述第一用户设置跟踪标识之后,在对所述第一用户进行信令跟踪的时长大于预设时长的情况下,所述业务网元取消对所述第一用户进行的信令跟踪;所述业务网元检测接收到的第二用户发送的业务消息携带的业务消息的第一参数是否满足所述跟踪条件;如果所述第二用户发送的业务消息携带的业务消息的第一参数满足所述跟踪条件,则所述业务网元为所述第二用户设置跟踪标识。第二用户可以是除第一用户以外,业务网元接收到的任一消息所属的用户。

另一种情况下,所述业务网元为所述第一用户设置跟踪标识之后,在对所述第一用户进行信令跟踪的时长大于预设时长的情况下,所述业务网元检测接收到的第二用户发送的业务消息携带的业务消息的第一参数是否满足所述跟踪条件;如果所述第二用户发送的业务消息携带的业务消息的第一参数满足所述跟踪条件,则所述业务网元取消对所述第一用户进行的信令跟踪,为所述第二用户设置跟踪标识。

本申请实施例中,通过设置最大跟踪用户数来限定业务网元同时进行信令流程跟踪的最大阈值。为了收集更多的网络故障对应的用户的信令消息样本进行分析,业务网元可以设定一个切换时长,当对一个目标用户的信令消息进行跟踪的持续时间达到该切换时长后,停止对该用户的信令跟踪,并重新选择符合跟踪条件的用户继续进行信令跟踪,即检测接收到的第二用户发送的业务消息携带的业务消息的第一参数是否满足所述跟踪条件,如果所述第二用户发送的业务消息携带的业务消息的第一参数满足所述跟踪条件,则所述业务网元为所述第二用户设置跟踪标识。。

举例说明,业务网元可以设置切换时长为5分钟,则从业务网元对用户A的信令流程进行跟踪时开始计时。当业务网元对该用户A进行信令流程跟踪时长达到5分钟后,重新选择满足跟踪条件的新用户B并对该新用户B进行信令流程跟踪。另外,由于在到达切换时长的瞬间并不一定立刻能找到满足跟踪条件的新用户,业务网元可以在到达切换时长后继续对原来的用户A进行信令流程跟踪,并上报A用户的信令流程,同时寻找新的符合跟踪条件的目标用户,在成功找到新的符合跟踪条件的目标用户B并对新的目标用户B进行信令流程跟踪后再进行切换,即停止对用户A的信令流程跟踪。停止对用户A的信令流程跟踪即是说,用户A的跟踪标识无效,不再对用户A进行信令流程跟踪,也不再向LMT上报用户A的信令流程。

业务网元对每个跟踪的用户进行跟踪的开始时间可能不同,因此,在同一时刻,业务可能对多个用户进行信令流程跟踪。然而,由于跟踪的用户开始跟踪的时间不同,当设置了切换时长时,跟踪的用户的停止跟踪时间也可能会不同。那么,在任一个跟踪的用户的跟踪时长达到切换时长时,停止对该目标用户的信令流程跟踪。重新选择符合跟踪条件的目标用户,且重新选择后,网元跟踪的用户的数目不能超过最大跟踪用户数。

在实际应用场景中,由于根据跟踪条件确定的跟踪的用户的业务流程存在网络故障的可能性较大,业务网元也可以不设置切换时长,而是对该符合跟踪条件的用户进行持续跟踪,直到网络故障定位成功为止。

当某个用户碰到一个业务失败的场景,用户很大可能会重试上述失败的业务场景,由于重试时用户的很多业务参数不会立即改变,某个用户碰到一个业务失败的场景,该用户在短时间内再次碰到该业务失败场景的几率非常高。可以跟踪该用户就能抓到业务失败的场景,从而分析出网络故障发生的具体原因,加速故障的排除。本申请实施例不需要通过用户投诉来获得发生故障的用户的标识,只需要根据故障引起的跟踪参数变化,确定业务消息的过滤条件,即跟踪条件。业务网元可以获取满足跟踪条件用户的信令流程,从而从业务网元同时处理的大量用户的信令流程中过滤出满足跟踪条件的用户进行信令流程跟踪。从而更容易分析出网络故障发生的具体原因和场景,可以更快的确定网络故障,提高了网络故障的定位效率。

上述详细阐述了本申请实施例的方法,下面提供了本申请实施例提供的设备。

基于图1的网络系统架构,图6是本申请实施例提供的另一种业务网元30的结构示意图。该业务网元可以是图4所描述的网络设备。如图6所示,该业务网元30可以包括接收单元301、检测单元302和设置单元303,其中:

接收单元301,用于接收第一用户发送的业务消息,所述业务消息携带所述业务消息的第一参数;所述第一参数包括以下至少一项:业务类型、消息类型、用户类型、接口原因值、全局失败原因值和业务消息字段取值;

检测单元302,用于检测所述业务消息的第一参数是否满足跟踪条件;所述跟踪条件用于指示第一故障发生时所述第一参数的取值;

设置单元303,用于如果所述业务消息的第一参数满足所述跟踪条件,则为所述第一用户设置跟踪标识,所述跟踪标识用于指示对所述第一用户进行信令跟踪以获取所述第一用户的信令流程,所述第一用户的信令流程用于进行网络故障定位。

作为一种可能的实施方式,检测单元302,还用于如果所述业务消息的第一参数满足所述跟踪条件,检测已跟踪的用户数是否小于最大跟踪用户数;在检测单元302检测到所述已跟踪的用户数小于所述最大跟踪用户数的情况下,设置单元303为所述第一用户设置跟踪标识。

作为一种可能的实施方式,设置单元303为第一用户设置跟踪标识之后,设置单元303,还用于在对所述第一用户进行信令跟踪的时长大于预设时长的情况下,取消对所述第一用户进行的信令跟踪;检测单元302,还用于检测接收到的第二用户发送的业务消息携带的业务消息的第一参数是否满足所述跟踪条件;如果所述第二用户发送的业务消息携带的业务消息的第一参数满足所述跟踪条件,则设置单元303,还用于为所述第二用户设置跟踪标识。

作为一种可能的实施方式,设置单元303为所述第一用户设置跟踪标识之后,检测单元302,还用于在对所述第一用户进行信令跟踪的时长大于预设时长的情况下,检测接收到的第二用户发送的业务消息携带的业务消息的第一参数是否满足所述跟踪条件;如果检测单元302检测到第二用户发送的业务消息携带的业务消息的第一参数满足所述跟踪条件,则设置单元303,还用于取消对所述第一用户进行的信令跟踪,为所述第二用户设置跟踪标识。

作为一种可能的实施方式,业务网元30还包括发送单元304,用于设置单元303为所述第一用户设置跟踪标识之后,将第一用户的信令流程发送给终端10,所述第一用户的信令流程用于所述终端10根据所述第一用户的信令流程进行网络故障定位。

作为一种可能的实施方式,接收单元301接收第一用户发送的业务消息之前,接收单元301,还用于接收网络设备20发送的携带跟踪条件的跟踪任务信息;所述跟踪任务信息是所述终端10发送给所述网络设备20的。

在该实施例中,业务网元30中接收单元301、检测单元302、设置单元303和发送单元304的功能可以对应参照图5所示的网络故障定位实施例的相应描述,这里不再赘述。

基于图1的网络系统架构,图7是本申请实施例提供的另一种本地维护终端10的结构示意图。该本地维护终端10可以是图2所描述的本地维护终端。如图7所示,该本地维护终端10可以包括发送单元101和处理单元102,其中:

处理单元102,用于生成携带跟踪条件的跟踪任务信息;

发送单元101,用于向网络设备20发送携带跟踪条件的跟踪任务信息;

所述跟踪条件用于业务网元30检测业务消息的第一参数是否满足所述跟踪条件,当所述业务消息的第一参数满足所述跟踪条件时,为第一用户设置跟踪标识;所述第一参数包括以下至少一项:业务类型、消息类型、用户类型、接口原因值和业务消息字段取值;所述跟踪条件指示第一故障发生时所述第一参数的取值;所述业务消息的第一参数是所述业务网元30接收到所述第一用户发送的业务消息中携带的;所述跟踪标识用于指示对所述第一用户进行信令跟踪以获取所述第一用户的信令流程,所述第一用户的信令流程用于进行网络故障定位。

作为一种可能的实施方式,该本地维护终端10还可以包括接收单元103,用于接收所述网络设备20发送的携带所述第一用户的信令流程的消息;所述携带所述第一用户的信令流程的消息是所述业务网元30发送给所述网络设备20的。

在该实施例中,本地维护终端10中发送单元101、处理单元102和接收单元103的功能可以对应参照图5所示的网络故障定位实施例的相应描述,这里不再赘述。

基于图1的网络系统架构,图8是本申请实施例提供的另一种网络设备20的结构示意图。该网络设备20可以是图3所描述的网络设备。如图7所示,该网络设备20可以包括接收单元201、发送单元202和处理单元203,其中:

接收单元201,用于接收本地维护终端10发送的携带跟踪条件的跟踪任务信息;

发送单元202,用于将所述跟踪任务信息发送给业务网元30;

处理单元203,用于存储和分配携带跟踪条件的跟踪任务信息。

所述跟踪条件用于业务网元30检测业务消息的第一参数是否满足所述跟踪条件,当所述业务消息的第一参数满足所述跟踪条件时,为第一用户设置跟踪标识;所述第一参数包括以下至少一项:业务类型、消息类型、用户类型、接口原因值和业务消息字段取值;所述跟踪条件指示第一故障发生时所述第一参数的取值;所述业务消息的第一参数是所述业务网元30接收到所述第一用户发送的业务消息中携带的;所述跟踪标识用于指示对所述第一用户进行信令跟踪以获取所述第一用户的信令流程,所述第一用户的信令流程用于进行网络故障定位。

作为一种可能的实施方式,接收单元201,还用于接收所述业务网元30发送的携带所述第一用户的信令流程的消息;发送单元202,还用于将携带所述第一用户的信令流程的消息发送给本地维护终端10。

在该实施例中,网络设备20中接收单元201、发送单元202和处理单元203的功能可以对应参照图5所示的网络故障定位实施例的相应描述,这里不再赘述。

结合本发明实施例公开内容所描述的方法或者算法的步骤可以硬件的方式来实现,也可以是由处理器执行软件程序指令的方式来实现。软件程序指令可以由相应的软件模块组成,软件模块可以被存放于RAM、闪存、ROM、可擦除可编程只读存储器(erasable programmable ROM,EPROM)、电可擦可编程只读存储器(electrically EPROM,EEPROM)、寄存器、硬盘、移动硬盘、只读光盘(CD-ROM)或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器,从而使处理器能够从该存储介质读取信息,且可向该存储介质写入信息。当然,存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。另外,该ASIC可以位于收发机或中继设备中。当然,处理器和存储介质也可以作为分立组件存在于第一设备或第二设备中。

可以理解的是,在本申请中,不同实施例之间的技术术语、技术方案可以依据其内在的逻辑相互参考、相互引用,本申请并不对技术术语和技术方案所适用的实施例进行限定。对不同实施例中的技术方案相互组合,还可以形成新的实施例。

可以理解的是,本申请的实施例中的处理器可以是中央处理单元(central processing unit,CPU),还可以是其他通用处理器、数字信号处理器(digital signal processor,DSP)、专用集成电路(application specific integrated circuit,ASIC)、现场可编程门阵列(field programmable gate array,FPGA)或者其他可编程逻辑器件、晶体管逻辑器件,硬件部件或者其任意组合。通用处理器可以是微处理器,也可以是任何常规的处理器。

在上述实施例中,可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时,可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时,全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中,或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质,(例如,软盘、硬盘、磁带)、光介质(例如,DVD)、或者半导体介质(例如,固态硬盘(solid state disk,SSD))等。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程,该流程可以由计算机程序来指令相关的硬件完成,该程序可存储于计算机可读取存储介质中,该程序在执行时,可包括如上述各方法实施例的流程。而前述的存储介质包括:ROM或随机存储记忆体RAM、磁碟或者光盘等各种可存储程序代码的介质。

再多了解一些
当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1