CN105071968A - 一种通信设备的业务面和控制面的隐性故障修复方法和装置 - Google Patents

Abstract

本申请实施例提供了一种通信设备的业务面和控制面的隐性故障修复方法，所述通信设备中包括一个或多个通信组件，所述的方法包括：分别获取通信设备的业务面关键指标KPI，以及，控制面关键指标KPI；根据所述控制面关键指标KPI，确定通信设备中发生控制面隐性故障的一个或多个通信组件；根据所述业务面关键指标KPI，确定通信设备中发生业务面隐性故障的一个或多个通信组件；对所述一个或多个故障的通信组件进行修复。本申请通过通信设备已有的关键指标KPI检测控制面和业务面的隐性故障，不需增加通信设备额外的处理负荷。

Description

一种通信设备的业务面和控制面的隐性故障修复方法和装置

技术领域

本申请涉及通信设备技术领域，特别是涉及一种通信设备的业务面和控制面的隐性故障修复方法和一种通信设备的业务面和控制面的隐性故障修复装置。

背景技术

通信网络设备故障分为显性和隐性，显性故障一般指可通过OMC(OperationandMaintenanceCenter，操作维护中心)网管的告警信息进行监控和管理的诸如心跳检测监守超时的硬件板卡故障、软件运行异常引起的板卡复位故障，或者传输闪断告警、或者通信服务单元故障(如通信设备中基站退服、载波故障等)。隐性故障指OMC监控中没有任何设备故障告警，但设备处于非正常工作状态，对指标产生负面影响和降低用户感知度的故障，此类故障发生时，用户感觉无法正常呼叫或者进行业务。

隐性故障产生可能由于软件或者硬件产生故障且隐性故障的发生具备随机性。例如软件长时间运行引起的挂内存、定时器、呼叫逻辑实体等软件资源的情况导致设备不能正常工作。或者由于设备长时间运行引起的诸如芯片老化、节点虚焊连接异常导致设备不能正常工作。

这些问题严重影响网络质量和用户感知，因此，隐性问题的主动发现和快速解决，对于提升用户满意度，保证网络性能，具有非常重要的意义。

发明内容

鉴于上述问题，提出了本申请实施例以便提供一种克服上述问题或者至少部分地解决上述问题的一种通信设备的业务面和控制面的隐性故障修复方法和相应的一种通信设备的业务面和控制面的隐性故障修复装置。

为了解决上述问题，本申请实施例公开了一种一种通信设备的业务面和控制面的隐性故障修复方法，其中，所述通信设备中包括一个或多个通信组件，所述的方法包括：

分别获取通信设备的业务面关键指标KPI，以及，控制面关键指标KPI；

根据所述控制面关键指标KPI，确定通信设备中发生控制面隐性故障的一个或多个通信组件；

根据所述业务面关键指标KPI，确定通信设备中发生业务面隐性故障的一个或多个通信组件；

对所述一个或多个故障的通信组件进行修复。

优选的，所述通信组件为软件模块、呼叫逻辑实体、硬件板卡本体和/或硬件板卡物理实体，所述根据所述控制面关键指标KPI，确定通信设备中发生控制面隐性故障的一个或多个通信组件的步骤包括：

采用所述控制面关键指标KPI确定所述控制面中发生的异常事件；

定位发生所述异常事件的通信组件；

统计所述异常事件发生的次数；

当所述次数满足预设的阈值时，将当前通信组件确定为发生控制面隐性故障的通信组件。

优选的，所述根据所述业务面关键指标KPI，确定通信设备中发生业务面隐性故障的一个或多个通信组件的步骤包括：

采用所述业务面关键指标KPI，确定所述业务面中发生的异常事件；

定位发生所述异常事件的通信组件；

统计所述异常事件发生的次数；

当所述次数满足预设的阈值时，将当前通信组件确定为发生业务面隐性故障的通信组件。

优选的，所述呼叫逻辑实体安装在硬件板卡本体或硬件板卡物理实体；

所述对所述一个或多个故障的通信组件进行修复的步骤包括：

当发生异常事件的通信组件为单个呼叫逻辑实体时，对所述通信组件进行重启；

若重启后所述异常事件仍然存在；则判断所述通信组件是否可以隔离；

若是，则对所述通信进行隔离；

若否，或，若隔离所述通信组件后，所述异常事件仍然存在；则重启所述通信组件所在的硬件板卡本体或硬件板卡物理实体。

优选的，所述硬件板卡物理实体安装在硬件板卡本体上；

所述对所述一个或多个故障的通信组件进行修复的步骤还包括：

当发生异常事件的通信组件为单个硬件板卡本体或硬件板卡物理实体时，判断所述通信组件是否可以隔离；

若是，则对所述通信组件进行隔离；

若否，则重启所述通信组件的物理板卡本体或硬件板卡物理实体所在硬件板卡本体。

优选的，所述对所述一个或多个故障的通信组件进行修复的步骤还包括：

当发生异常事件的通信组件包括：至少一个呼叫逻辑实体，和/或，硬件板卡本体，和/或，硬件板卡物理实体时，对通信组件进行连通性检测；

判断联通性检测失败的通信组件是否可以隔离；

若是，则对所述联通性检测失败的通信组件进行隔离；

若否，或，若隔离所述联通性检测失败的通信组件后，异常事件仍然存在；则重启所述联通性检测失败的通信组件中的硬件板卡本体，和/或，呼叫逻辑实体所在的硬件板卡本体，和/或，硬件板卡物理实体所在的物理板卡本体；

若重启后，异常事件仍然存在，则上报告警进行人力干预。

优选的，所述阈值包括：静态阈值和动态阈值；

所述静态阈值用于判断不随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障；

所述动态阈值用于判断随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障。

同时，本申请还公开了一种通信设备的业务面和控制面的隐性故障修复装置，其中，所述通信设备中包括一个或多个通信组件，所述的装置包括：

获取模块，分别获取通信设备的业务面关键指标KPI，以及，控制面关键指标KPI；

控制面隐性故障确定模块，用于根据所述控制面关键指标KPI，确定通信设备中发生控制面隐性故障的一个或多个通信组件；

业务面隐性故障确定模块，用于根据所述业务面关键指标KPI，确定通信设备中发生业务面隐性故障的一个或多个通信组件；

修复模块，用于对所述一个或多个故障的通信组件进行修复。

优选的，所述通信组件为软件模块、呼叫逻辑实体、硬件板卡本体和/或硬件板卡物理实体；所述控制面隐性故障确定模块进一步包括：

控制面异常事件确定子模块，用于采用所述控制面关键指标KPI确定所述控制面中发生的异常事件；

控制面异常事件定位子模块，用于定位发生所述异常事件的通信组件；

控制面异常事件统计子模块，用于统计所述异常事件发生的次数；

控制面隐性故障组件确定子模块，用于当所述次数满足预设的阈值时，将当前通信组件确定为发生控制面隐性故障的通信组件。

优选的，所述业务面隐性故障确定模块进一步包括：

业务面异常事件确定子模块，用于采用所述业务面关键指标KPI，确定所述业务面中发生的异常事件；

业务面异常事件定位子模块，用于定位发生所述异常事件的通信组件；

业务面异常事件统计子模块，用于统计所述异常事件发生的次数；

业务面隐性故障组件确定子模块，用于当所述次数满足预设的阈值时，将当前通信组件确定为发生业务面隐性故障的通信组件。

优选的，所述呼叫逻辑实体安装在硬件板卡本体或硬件板卡物理实体；

所述修复模块进一步包括：

第一逻辑重启子模块，用于当发生异常事件的通信组件为单个呼叫逻辑实体时，对所述通信组件进行重启；

第一判断子模块，用于若重启后所述异常事件仍然存在；则判断所述通信组件是否可以隔离；

第一隔离子模块，用于若所述第一判断子模块判断结果为是，则对所述通信进行隔离；

第一硬件重启子模块，用于若所述第一判断子模块判断结果为否，或，若隔离所述通信组件后，所述异常事件仍然存在；则重启所述通信组件所在的硬件板卡本体或硬件板卡物理实体。

优选的，所述硬件板卡物理实体安装在硬件板卡本体上；

所述修复模块还进一步包括：

第二判断子模块，用于当发生异常事件的通信组件为单个硬件板卡本体或硬件板卡物理实体时，判断所述通信组件是否可以隔离；

第二隔离子模块，用于若所述第二判断子模块判断结果为是，则对所述通信组件进行隔离；

第二硬件重启子模块，用于若所述第二判断子模块判断结果为否，则重启所述通信组件的物理板卡本体或硬件板卡物理实体所在硬件板卡本体。

优选的，所述修复模块还进一步包括：

连通性检测子模块，用于当发生异常事件的通信组件包括：至少一个呼叫逻辑实体，和/或，硬件板卡本体，和/或，硬件板卡物理实体时，对通信组件进行连通性检测；

第三判断子模块，用于判断联通性检测失败的通信组件是否可以隔离；

第三隔离子模块，用于若所述第三判断子模块的判断结果为是，则对所述联通性检测失败的通信组件进行隔离；

第三硬件重启子模块，用于若所述第三判断子模块的判断结果为否，或，若隔离所述联通性检测失败的通信组件后，异常事件仍然存在；则重启所述联通性检测失败的通信组件中的硬件板卡本体，和/或，呼叫逻辑实体所在的硬件板卡本体，和/或，硬件板卡物理实体所在的物理板卡本体；

上报警告子模块，用于若重启后，异常事件仍然存在，则上报告警进行人力干预。

优选的，所述阈值包括：静态阈值和动态阈值；

所述静态阈值用于判断不随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障；

所述动态阈值用于判断随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障。

本申请实施例包括以下优点：

本申请通过通信设备已有的关键指标KPI检测控制面和业务面的隐性故障，不需增加通信设备额外的处理负荷；

本申请根据控制面关键指标KPI检测导致信令失败的控制面隐性故障，并且可以同时根据业务面关键指标KPI检测导致用户感知变差的业务面隐性故障。

本申请根据发生隐性故障的类型和数目，采用不同的自愈和逐级回复手段，提升网络运维的方便性。

附图说明

图1是本申请的一种通信设备的业务面和控制面的隐性故障修复方法实施例的步骤流程图；

图2是本申请的一种通信设备的业务面和控制面的隐性故障修复方法实施例的示意图；

图3是本申请的一种通信设备的业务面和控制面的隐性故障修复装置实施例的结构框图。

具体实施方式

为使本申请的上述目的、特征和优点能够更加明显易懂，下面结合附图和具体实施方式对本申请作进一步详细的说明。

本申请实施例的核心构思之一在于，通过通信设备已有的关键指标KPI检测控制面和业务面的隐性故障，根据发生隐性故障的类型和数目，采用不同自愈和逐级回复手段。

参照图1，示出了本申请的一种通信设备的业务面和控制面的隐性故障修复方法实施例的步骤流程图，其中，所述通信设备中包括一个或多个通信组件，具体可以包括如下步骤：

步骤101，分别获取通信设备的业务面关键指标KPI，以及，控制面关键指标KPI；

步骤102，根据所述控制面关键指标KPI，确定通信设备中发生控制面隐性故障的一个或多个通信组件；

步骤103，根据所述业务面关键指标KPI，确定通信设备中发生业务面隐性故障的一个或多个通信组件；

步骤104，对所述一个或多个故障的通信组件进行修复。

在本申请实施例中，隐性故障分为业务面隐性故障和控制面隐性故障。控制面是指在通信设备中建立、修改、释放话务通路或者数据通路的不同网元之间各协议层间相互交互的信令过程。在信令交互过程中，不同网元之间协商出承载具体话音或者数据的ATM或者IP通路，称之为业务面。控制面过程异常，表现为用户感觉打不通电话，例如拨号后无法接通或者无法刷新网页等情况。如果业务面异常，表现为用户感知差，例如接通后听不到对方说话或者有杂音等情况、或者表现为网页刷新慢、无法下载等情况。

在隐性故障发生时往往伴随控制面和业务面KPI异常，隐性故障主要是通过呼叫流程中KPI是否突变来监控网络资源，特别是重要KPI的突变意味着网络质量发生严重的质量问题。关键指标KPI(KeyPerformanceIndication)是通信设备(诸如基站、RNC(RadioNetworkController，无线网络控制器)、核心网)等设备运行质量的总体统计，提供了设备运行质量的最基本信息。当通信设备发生隐性故障时，往往伴随设备指标异常出现。反映系统运行质量的KPI有：呼叫成功率、话务量、流量等。这些指标的突降可能由于无线设备出现硬件或者软件问题，因此，通过监控重点KPI的变化情况，能够提前发现网络的隐性问题，及时处理，保障用户感知。

关键指标KPI异常可以表现为：单位时间或者定时统计的KPI指标明显低于或者高于设备设定的阀值，或者，单位时间或者定时统计的KPI指标同历史统计值比较发生明显变坏趋势。

在本申请中，关键指标KPI分为：业务面关键指标KPI和控制面关键指标KPI。

如表1所示，为RNC设备的关键指标KPI示例；

通信设备包括一个或多个通信组件，通信组件具体可以为：软件模块(例如：协议模块、传输模块、驱动模块)、呼叫逻辑实体(例如：小区CELL、基站、载波)、硬件板卡本体(例如：DSP板卡、信令板、接口板)、物理板卡物理实体；

对通信网络来说，每次用户通话，会产生一条呼叫记录对应的信令流和数据流。信令流及数据流经过的硬件板卡的路径和软件模块的路径在通信设备设计时就定义和部署好。因此，可根据信令流程失败的点和数据流发生问题的点确认故障所处的软件模块和硬件板卡本体以及软件模块对应的呼叫逻辑实体和硬件板卡上的物理实体。

控制面对单次呼叫分配的数据通路为接续关系。以RNC设备为例，RNC设备包括接口板、业务板和信令板。RNC设备通过无线网络控制面信令协议建立端到端的业务链路，业务链路的层2协议实体由传输层承载，传输层部署在接口板上，层2协议部署在业务板上，无线信令处理部署在信令板上，信令板收发信令实现呼叫管理，按照呼叫属性在业务板上分配业务处理资源，在接口板上分配接口处理资源并实现接口板和业务板间的接续，在内部接续完成后，通过网元间信令过程通知其他网元，完成信令流程，业务接通。RNC设备内部板卡之间为全IP(InternetProtocol，网络协议)交换，根据设备单板对应的架框槽可以计算每个单板对应的内部IP地址。

对每个硬件板卡可根据架框槽计算内部IP地址，设备对外呈现IP地址或者ATM(AsynchronousTransferMode，异步传输模式)对应的VPI(VirtualPathIdentifier，虚路径标识符)/VCI(VirtualChannelIdentifier，虚通道标识符)为局数据同对端网元协商且通过局间消息互相通知。每次呼叫控制面信令分配的UDP(UserDatagramProtocol，用户数据协议)端口或者CID(ConnectionIdentifier，连接标识符)通过局向信令(NBAP(NodeBApplicationPart，基站应用部分协议)或者RANAP(RadioAccessNetworkApplicationPart，无线接入网络应用部分协议))互相通知给对端网元(NodeB或者CN(CoreNetwork，核心网))。因此，每次CS(CircuitSwitch，电路交换)语音或者PS(PacketSwitch，分组交换)数据业务控制面信令在RNC设备内部不同功能单板之间和外部同CN及NodeB建立以下接续关系：

内部板卡IP-内部板卡端口-RNC本端对外IP和本端对外UDP端口(或者VPI/VCI/CID)-对端网元IP和对端网元UDP端口(或者VPI/VCI/CID)。

这些接续关系在信令层面建立成功后，话音或者数据在这些接续关系上承载(不同板卡上不同协议模块处理语音或者数据，例如接口板处理传输协议，业务板处理层2协议)。对RNC设备来说，接续关系由控制面信令过程分配和建立，CS语音和PS数据流承载在这些接续关系上。即通过控制面信令过程建立业务面，业务面承载具体的数据流。因此，控制面信令过程的KPI和业务面表征QOS(QualityofService，服务质量)的KPI可反映控制面和业务面是否存在故障且可将隐性故障发生的位置点归属到特定的软件模块(例如协议模块、传输模块、驱动模块)或者特定呼叫逻辑实体(Cell小区、基站、载波)或者特定硬件板卡(DSP(digitalsignalprocessing，数字信号处理)板卡、信令板、接口板)或者特定硬件板卡物理实体(Path通道、IP)。由于软件模块中的呼叫逻辑实体部署在特定硬件板卡或者物理实体上，因此确定软件故障点的同时，可确定硬件故障点。

作为本申请实施例的一种优选示例，所述步骤102具体可以包括：

子步骤201，采用所述控制面关键指标KPI确定所述控制面中发生的异常事件；

子步骤202，定位发生所述异常事件的通信组件；

子步骤203，统计所述异常事件发生的次数；

子步骤204，当所述次数满足预设的阈值时，将当前通信组件确定为发生控制面隐性故障的通信组件。

控制面隐性故障通过控制面KPI来检测，控制面KPI可以反映信令流程中的信令状态，例如，CS或者PS接通率。通过检测控制面KPI可以确定所发生的异常事件，由于控制面的信令流程在通信设备设计时就定义和部署好，因此，通过发生的异常事件在信令流程中的位置就可以确定发生的通信组件。

统计一段时间内该通信组件的异常事件发生的次数，当该通信组件的异常事件发生的次数大于预设的预设的阈值时，将该通信组件确定为发生控制面隐性故障的通信组件，其中，预设的阈值的大小根据实际情况来。

例如，根据呼叫信令流程分析KPI变差点在呼叫信令流中的位置确认所发生的异常事件，再分析KPI变差是否集中在TOP呼叫逻辑实体(如TOPCELL、载波、基站)或者呼叫的实体UE接入的硬件板卡或硬件板卡物理实体上。KPI的统计以呼叫逻辑实体、硬件板卡本体和硬件板卡物料单元统计。

作为本申请实施例的一种优选示例，所述步骤103具体可以包括：

子步骤301，采用所述业务面关键指标KPI，确定所述业务面中发生的异常事件；

子步骤302，定位发生所述异常事件的通信组件；

子步骤303，统计所述异常事件发生的次数；

子步骤304，当所述次数满足预设的阈值时，将当前通信组件确定为发生业务面隐性故障的通信组件。

业务面隐性故障表现为业务面通路的服务器质量QOS下降，业务面通路是否可达可以通过iuUP和iub节点同步以及ECHO回应等过程进行。业务面通路的服务质量QOS可通过误块率、丢包率、RTT时延、PS业务流量、CS语音流量等用户感知类的业务面KPI来表示。

由于业务面的通路在控制面的信令过程中已建立好，因此，通过发生的异常事件在业务面通路中的位置就可以确定发生的通信组件。统计一段时间内该通信组件的异常事件发生的次数，当该通信组件的异常事件发生的次数大于预设的预设的阈值时，将该通信组件确定为发生控制面隐性故障的通信组件，其中，预设的阈值的大小根据实际情况来。

业务面通路的检测针对单个用户感知进行统计。多个用户感知的统计结果可反映网络中的隐性问题，如果多个用户出现问题均发生在特定的业务板上，这个业务板发生隐性故障。

在本申请实施例中，所述阈值包括：静态阈值和动态阈值；

所述静态阈值用于判断不随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障；

所述动态阈值用于判断随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障。

静态阈值，用于判断不随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障。例如接通率KPI，接通率KPI并不随时间周期变化，可以使用静态阈值进行判断。动态阀值，用于判断随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障。动态阈值时根据一定时期的历史指标数据，计算得出的阀值。例如：针对PATH上的流量KPI，由于存在忙闲时，因此，需要结合历史上一周闲时的流量统计结果给出这个流量KPI的阀值。

在确定了发生控制面隐性故障或业务面隐性故障的通信元件之后，需要对这些通信组件进行修复。在本申请实施例中，通信组件的修复，根据发生异常事件的通信组件的数目和类型进行不同的自愈和回复手段，提升网络运维的方便性。

作为本申请实施例的一个优选示例，所述步骤104具体可以包括：

子步骤401，当发生异常事件的通信组件为单个呼叫逻辑实体时，对所述通信组件进行重启；所述呼叫逻辑实体安装在硬件板卡本体或硬件板卡物理实体；

子步骤402，若重启后所述异常事件仍然存在；则判断所述通信组件是否可以隔离；

子步骤403，若是，则对所述通信进行隔离；

子步骤404，若否，或，若隔离所述通信组件后，所述异常事件仍然存在；则重启所述通信组件所在的硬件板卡本体或硬件板卡物理实体。

通过关键指标KPI可以确定所发生的异常事件，以及确定发生异常事件的通信组件。有的异常事件可能是由一个通信组件故障引起，有的可能是由多个通信组件故障引起。

当发生异常事件的通信组件为单个呼叫逻辑实体时，对该通信组件进行重启；若重启后异常事件仍然存在；则判断通信组件是否可以隔离，通信组件是否隔离隔离的判断标准是，通信设备中是否具有可以替代发生通信故障的通信组件的的后备通信组件。如存在后备通信组件，则可以采用后备通信组件替换发生异常事件的通信组件，使该故障的通信组件被隔离。若故障的通信组件不能被隔离，或者，隔离后异常事件仍然存在，则重启故障的通信组件所在的硬件板卡本体或硬件板卡物理实体。呼叫逻辑实体安装在硬件板卡本体或硬件板卡物理实体，呼叫逻辑实体的异常可能由呼叫逻辑实体所在的硬件板卡本体或硬件板卡物理实体引起。

作为本申请实施例的一种优选示例，所述步骤104还可以包括：

子步骤501，当发生异常事件的通信组件为单个硬件板卡本体或硬件板卡物理实体时，判断所述通信组件是否可以隔离；

子步骤502，若是，则对所述通信组件进行隔离；

子步骤503，若否，则重启所述通信组件的物理板卡本体或硬件板卡物理实体所在硬件板卡本体。

当发生异常事件的通信组件为单个硬件板卡本体或硬件板卡物理实体时，判断该通信组件是否可以隔离；当具有后备的通信组件时，将该通信组件进行隔离；若不具有后备的通信组件，则重启所述通信组件的物理板卡本体或硬件板卡物理实体所在硬件板卡本体，硬件板卡物理实体安装在硬件板卡本体上。

作为本申请实施例的一种优选示例，所述步骤104还可以包括：

子步骤601，当发生异常事件的通信组件包括：至少一个呼叫逻辑实体，和/或，硬件板卡本体，和/或，硬件板卡物理实体时，对通信组件进行连通性检测；

子步骤602，判断联通性检测失败的通信组件是否可以隔离；

子步骤603，若是，则对所述联通性检测失败的通信组件进行隔离；

子步骤604，若否，或，若隔离所述联通性检测失败的通信组件后，异常事件仍然存在；则重启所述联通性检测失败的通信组件中的硬件板卡本体，和/或，呼叫逻辑实体所在的硬件板卡本体，和/或，硬件板卡物理实体所在的物理板卡本体；

子步骤605，若重启后，异常事件仍然存在，则上报告警进行人力干预。

若某个异常事件可能是由多个通信组件的集合引起的，则对这些通信组件进行控制面和业务面的连通性检测，例如，某个异常事件是由A组件和B组件引起的，对A、B组件进行连通性检测。连通性检测的过程具体可以为：A向B发送数据，如果A发送不出去，则A发生了故障，如果是B接收不到，则B发生了故障。如果通信组件经连通性检测为正常，则将正常的通信组件从通信组件的集合中排除，进一步缩小发生故障的范围。

在联通性检测之后，判断联通性检测失败的通信组件是否可以隔离；若具有后备的通信组件，则将联通性检测失败的通信组件进行隔离。若不具有后备的通信组件或者隔离后异常事件仍然存在，则重启联通性检测失败的通信组件中的硬件板卡本体，和/或，呼叫逻辑实体所在的硬件板卡本体，和/或，硬件板卡物理实体所在的物理板卡本体，若重启后，异常事件仍然存在，则上报告警进行人力干预。

参照图2，示出了本申请的一种通信设备的业务面和控制面的隐性故障修复方法实施例的示意图，具体可以包括：检测步骤、判决步骤、策略步骤和执行步骤。

检测步骤中通过检测模块来检测预定义异常事件是否发生；判决步骤中通过判决模块是否发生隐性故障；策略步骤中通过策略模块根据隐性故障的影响性和涉及范围确定修复方式；执行步骤中通过执行模块执行修复方式。

检测模块包括控制面监测模块和业务面监测模块；

控制面监测模块监测呼叫流程中的信令跟踪的失败点。对于控制面信令流程来说，每次用户通话(语音、数据、短信)，都需要设备同相关网元进行信令流程交互，这些交互的信令消息在设备内部由于协议栈的关系，由不同的单板上的不同子系统进行处理，在这个过程中，可能在某些软件环境或者信令链路的节点上出现问题，导致呼叫控制流程中断，因此，可根据呼叫流程中的信令跟踪的失败点来确认失败原因。例如：MSC和RNC之间的某条PATH数据链路异常，RNC在呼叫流程中配置IUUP协议层时会失败，因此信令过程时可以发现业务建立在这条链路时，失败率较高。通过闭塞该PATH后，即业务通路不在分配在这条PATH上后，指标恢复正常。

用户面监测模块检测流量、CRC错误等是否处于异常范围内。在控制面呼叫流程成功后，建立用户面处理的业务通路，在业务通路上传递数据和语音。用户面数据的协议处理模块也分布在设备内部的不同单板的不同子系统进行处理。因此，根据这些通路上数据业务流量是否正常、误码率是否在合理范围内，判断业务通路是否正常，如果异常，这条通路经过的所有处理板卡、软件模块可能存在异常，采取先软件重启的方式尝试恢复，如果无法恢复，尝试硬件重启。

判决模块：对控制面或者业务面异常发生时，判决模块检测判断KPI指标是否在处于异常范围内，KPI指标为多次呼叫成功或者失败的统计结果，指标变差就是呼叫流程失败的累积效应。通过指标分析，获取异常事件发生具备的呼叫逻辑实体或者部署物理单元的集中性。集中性可以理解为某个异常事件在在所有异常事件中的比例超过预设的范围，那么这个异常事件具有居中性。

控制面和业务面隐性故障判断原则：某个异常事件连续失败的次数(80次)，连续多次业务(例如100次)中失败高概率发生(例如失败80次)、或者连续几个周期内(可配置)接通率不合格。这些比例同预设置的阀值比较，如果高于阀值，进一步判断发生异常事件的呼叫逻辑实体(如CELL、NODEB、载波)是否存在集中的情况，如果呼叫逻辑实体不存在集中性，进一步判断呼叫逻辑实体部署的物理单元(如PATH、DSP、物理板卡)是否存在集中性。判决模块设置的判决阀值代表网元设备运行质量突变的门限，分两部分阀值：静态阀值，例如接通率KPI(一般设置的为大于99.5以上)。动态阀值：根据一定时期的历史指标数据，计算得出阀值，例如：针对PATH上的流量信息，由于存在忙闲时，因此，需要结合历史上一周闲时的流量统计结果给出这个异常阀值。

策略模块：在隐性故障发生时，采取措施恢复可能存在的隐性故障，避免故障的影响性扩大。策略模块根据异常事件的影响性和涉及范围，异常事件的影响性和涉及范围即KPI涉及的范围，不同的KPI涉及不同的通信组件，有的KPI可能是对应一个通信组件(单资源组件)。有的KPI可能对应多个通信组件(多资源集合)，策略模块判断隐性故障的通信组件是单资源组件，还是多资源组件的集合。如果是单资源专业化吧先尝试软件逻辑实体重启，后硬件逻辑实体处理，如果KPI对应的是软件逻辑实体，则先重启软件逻辑实体，后修复硬件实体。如果KPI对应的是硬件实体，则直接修复硬件实体如果是资源的集合，针对控制面和业务面进行连通性检测，进一步确定故障的通信组件。确定故障的通信组件后，首先根据隐性故障发生的范围(KPI所涉及的通信组件)，然后判断故障的通信组件是否可以隔离，是否可以隔离的判断标准是是否具有后备的通信组件。如果故障的通信可以隔离，先隔离故障的通信组件，避免业务持续恶化，如果不可以隔离就直接重启单板。在故障的通信组件范围扩大时，复位整个物理单板重新启动的方式用于自愈。在单位时间内多次重启无法解决时，及时上报告警给运维人员尝试人力干预。

例如对于设备资源吊死情况，通过软件复位可恢复。对于独立硬件资源故障的通信组件，例如一条PATH和DSP，可采取先隔离隔离此故障的通信组件，避免业务承载在此故障的通信组件上。如果某单板上PATH的80％已经隔离，尝试复位单板。在复位单板无效的情况下，直接上报告警提示运维人员干预。

在业务通路发生故障时，可能由于传输或者对端网元出问题，不响应本端设备发出的诸如ECHO、IUUP初始化、IUB同步请求等消息，因此，在检测出现通路故障后，需要发出连通性检测，一般采取软件或者硬件环回的方法，但在业务量大的情况下，软件环回或者硬件环回会导致出现环回消息风暴引起异常，本专利采取在业务通路出现问题时，发送检测报文时，报文头携带特殊标签，业务通路上每个软件模块收到检测报文后，给报文起始者发送响应报文，报文起始者根据通路上响应报文是否收齐判断是否内部接续关系建立的业务通路异常还是对端网元或者局间传输出现异常。

策略执行模块根据策略模块的要求执行复位单板或者隔离或者告警等操作。策略执行模块根据故障处理策略不同由不同软件系统执行。例如要求重启的单板，由系统管理模块执行。对故障的通信组件隔离的策略，要求资源分配模块参与，执行告警由告警处理模块参与。

需要说明的是，对于方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本申请实施例并不受所描述的动作顺序的限制，因为依据本申请实施例，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作并不一定是本申请实施例所必须的。

参照图3，示出了本申请的一种通信设备的业务面和控制面的隐性故障修复装置实施例的结构框图，其中，所述通信设备中包括一个或多个通信组件，所述装置具体可以包括如下模块：

获取模块301，分别获取通信设备的业务面关键指标KPI，以及，控制面关键指标KPI；

控制面隐性故障确定模块302，用于根据所述控制面关键指标KPI，确定通信设备中发生控制面隐性故障的一个或多个通信组件；

业务面隐性故障确定模块303，用于根据所述业务面关键指标KPI，确定通信设备中发生业务面隐性故障的一个或多个通信组件；

修复模块304，用于对所述一个或多个故障的通信组件进行修复。

作为本申请实施例的一种优选示例，所述通信组件为软件模块、呼叫逻辑实体、硬件板卡本体和/或硬件板卡物理实体；所述控制面隐性故障确定模块302进一步包括：

控制面异常事件确定子模块，用于采用所述控制面关键指标KPI确定所述控制面中发生的异常事件；

控制面异常事件定位子模块，用于定位发生所述异常事件的通信组件；

控制面异常事件统计子模块，用于统计所述异常事件发生的次数；

控制面隐性故障组件确定子模块，用于当所述次数满足预设的阈值时，将当前通信组件确定为发生控制面隐性故障的通信组件。

作为本申请实施例的一种优选示例，所述业务面隐性故障确定模块303进一步包括：

业务面异常事件确定子模块，用于采用所述业务面关键指标KPI，确定所述业务面中发生的异常事件；

业务面异常事件定位子模块，用于定位发生所述异常事件的通信组件；

业务面异常事件统计子模块，用于统计所述异常事件发生的次数；

业务面隐性故障组件确定子模块，用于当所述次数满足预设的阈值时，将当前通信组件确定为发生业务面隐性故障的通信组件。

作为本申请实施例的一种优选示例，所述呼叫逻辑实体安装在硬件板卡本体或硬件板卡物理实体；

所述修复模块304进一步包括：

第一逻辑重启子模块，用于当发生异常事件的通信组件为单个呼叫逻辑实体时，对所述通信组件进行重启；

第一判断子模块，用于若重启后所述异常事件仍然存在；则判断所述通信组件是否可以隔离；

第一隔离子模块，用于若所述第一判断子模块判断结果为是，则对所述通信进行隔离；

第一硬件重启子模块，用于若所述第一判断子模块判断结果为否，或，若隔离所述通信组件后，所述异常事件仍然存在；则重启所述通信组件所在的硬件板卡本体或硬件板卡物理实体。

作为本申请实施例的一种优选示例，所述硬件板卡物理实体安装在硬件板卡本体上；

所述修复模块304还进一步包括：

第二判断子模块，用于当发生异常事件的通信组件为单个硬件板卡本体或硬件板卡物理实体时，判断所述通信组件是否可以隔离；

第二隔离子模块，用于若所述第二判断子模块判断结果为是，则对所述通信组件进行隔离；

第二硬件重启子模块，用于若所述第二判断子模块判断结果为否，则重启所述通信组件的物理板卡本体或硬件板卡物理实体所在硬件板卡本体。

作为本申请实施例的一种优选示例，所述修复模块304还进一步包括：

连通性检测子模块，用于当发生异常事件的通信组件包括：至少一个呼叫逻辑实体，和/或，硬件板卡本体，和/或，硬件板卡物理实体时，对通信组件进行连通性检测；

第三判断子模块，用于判断联通性检测失败的通信组件是否可以隔离；

第三隔离子模块，用于若所述第三判断子模块的判断结果为是，则对所述联通性检测失败的通信组件进行隔离；

第三硬件重启子模块，用于若所述第三判断子模块的判断结果为否，或，若隔离所述联通性检测失败的通信组件后，异常事件仍然存在；则重启所述联通性检测失败的通信组件中的硬件板卡本体，和/或，呼叫逻辑实体所在的硬件板卡本体，和/或，硬件板卡物理实体所在的物理板卡本体。

上报警告子模块，用于若重启后，异常事件仍然存在，则上报告警进行人力干预。

作为本申请实施例的一种优选示例，所述阈值包括：静态阈值和动态阈值；

所述静态阈值用于判断不随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障；

所述动态阈值用于判断随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障。

对于装置实施例而言，由于其与方法实施例基本相似，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

本说明书中的各个实施例均采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似的部分互相参见即可。

本领域内的技术人员应明白，本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此，本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上，使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

尽管已描述了本申请实施例的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例做出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。

最后，还需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。

以上对本申请所提供的一种通信设备的业务面和控制面的隐性故障修复方法和一种通信设备的业务面和控制面的隐性故障修复装置，进行了详细介绍，本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想；同时，对于本领域的一般技术人员，依据本申请的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本申请的限制。

Claims (14)

1.一种通信设备的业务面和控制面的隐性故障修复方法，其特征在于，所述通信设备中包括一个或多个通信组件，所述的方法包括：

分别获取通信设备的业务面关键指标KPI，以及，控制面关键指标KPI；

根据所述控制面关键指标KPI，确定通信设备中发生控制面隐性故障的一个或多个通信组件；

根据所述业务面关键指标KPI，确定通信设备中发生业务面隐性故障的一个或多个通信组件；

对所述一个或多个故障的通信组件进行修复。

2.根据权利要求1所述的方法，其特征在于，所述通信组件为软件模块、呼叫逻辑实体、硬件板卡本体和/或硬件板卡物理实体，所述根据所述控制面关键指标KPI，确定通信设备中发生控制面隐性故障的一个或多个通信组件的步骤包括：

采用所述控制面关键指标KPI确定所述控制面中发生的异常事件；

定位发生所述异常事件的通信组件；

统计所述异常事件发生的次数；

当所述次数满足预设的阈值时，将当前通信组件确定为发生控制面隐性故障的通信组件。

3.根据权利要求1或2所述的方法，其特征在于，所述根据所述业务面关键指标KPI，确定通信设备中发生业务面隐性故障的一个或多个通信组件的步骤包括：

采用所述业务面关键指标KPI，确定所述业务面中发生的异常事件；

定位发生所述异常事件的通信组件；

统计所述异常事件发生的次数；

当所述次数满足预设的阈值时，将当前通信组件确定为发生业务面隐性故障的通信组件。

4.根据权利要求1所述的方法，其特征在于，所述呼叫逻辑实体安装在硬件板卡本体或硬件板卡物理实体；

所述对所述一个或多个故障的通信组件进行修复的步骤包括：

当发生异常事件的通信组件为单个呼叫逻辑实体时，对所述通信组件进行重启；

若重启后所述异常事件仍然存在；则判断所述通信组件是否可以隔离；

若是，则对所述通信进行隔离；

若否，或，若隔离所述通信组件后，所述异常事件仍然存在；则重启所述通信组件所在的硬件板卡本体或硬件板卡物理实体。

5.根据权利要求1所述的方法，其特征在于，所述硬件板卡物理实体安装在硬件板卡本体上；

所述对所述一个或多个故障的通信组件进行修复的步骤还包括：

当发生异常事件的通信组件为单个硬件板卡本体或硬件板卡物理实体时，判断所述通信组件是否可以隔离；

若是，则对所述通信组件进行隔离；

若否，则重启所述通信组件的物理板卡本体或硬件板卡物理实体所在硬件板卡本体。

6.根据权利要求4或5所述的方法，其特征在于，所述对所述一个或多个故障的通信组件进行修复的步骤还包括：

当发生异常事件的通信组件包括：至少一个呼叫逻辑实体，和/或，硬件板卡本体，和/或，硬件板卡物理实体时，对通信组件进行连通性检测；

判断联通性检测失败的通信组件是否可以隔离；

若是，则对所述联通性检测失败的通信组件进行隔离；

若否，或，若隔离所述联通性检测失败的通信组件后，异常事件仍然存在；则重启所述联通性检测失败的通信组件中的硬件板卡本体，和/或，呼叫逻辑实体所在的硬件板卡本体，和/或，硬件板卡物理实体所在的物理板卡本体；

若重启后，异常事件仍然存在，则上报告警进行人力干预。

7.根据权利要求3所述的方法，其特征在于，所述阈值包括：静态阈值和动态阈值；

所述静态阈值用于判断不随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障；

所述动态阈值用于判断随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障。

8.一种通信设备的业务面和控制面的隐性故障修复装置，其特征在于，所述通信设备中包括一个或多个通信组件，所述的装置包括：

获取模块，分别获取通信设备的业务面关键指标KPI，以及，控制面关键指标KPI；

控制面隐性故障确定模块，用于根据所述控制面关键指标KPI，确定通信设备中发生控制面隐性故障的一个或多个通信组件；

业务面隐性故障确定模块，用于根据所述业务面关键指标KPI，确定通信设备中发生业务面隐性故障的一个或多个通信组件；

修复模块，用于对所述一个或多个故障的通信组件进行修复。

9.根据权利要求8所述的装置，其特征在于，所述通信组件为软件模块、呼叫逻辑实体、硬件板卡本体和/或硬件板卡物理实体；所述控制面隐性故障确定模块进一步包括：

控制面异常事件确定子模块，用于采用所述控制面关键指标KPI确定所述控制面中发生的异常事件；

控制面异常事件定位子模块，用于定位发生所述异常事件的通信组件；

控制面异常事件统计子模块，用于统计所述异常事件发生的次数；

控制面隐性故障组件确定子模块，用于当所述次数满足预设的阈值时，将当前通信组件确定为发生控制面隐性故障的通信组件。

10.根据权利要求8或9所述的装置，其特征在于，所述业务面隐性故障确定模块进一步包括：

业务面异常事件确定子模块，用于采用所述业务面关键指标KPI，确定所述业务面中发生的异常事件；

业务面异常事件定位子模块，用于定位发生所述异常事件的通信组件；

业务面异常事件统计子模块，用于统计所述异常事件发生的次数；

业务面隐性故障组件确定子模块，用于当所述次数满足预设的阈值时，将当前通信组件确定为发生业务面隐性故障的通信组件。

11.根据权利要求8所述的装置，其特征在于，所述呼叫逻辑实体安装在硬件板卡本体或硬件板卡物理实体；

所述修复模块进一步包括：

第一逻辑重启子模块，用于当发生异常事件的通信组件为单个呼叫逻辑实体时，对所述通信组件进行重启；

第一判断子模块，用于若重启后所述异常事件仍然存在；则判断所述通信组件是否可以隔离；

第一隔离子模块，用于若所述第一判断子模块判断结果为是，则对所述通信进行隔离；

第一硬件重启子模块，用于若所述第一判断子模块判断结果为否，或，若隔离所述通信组件后，所述异常事件仍然存在；则重启所述通信组件所在的硬件板卡本体或硬件板卡物理实体。

12.根据权利要求8所述的装置，其特征在于，所述硬件板卡物理实体安装在硬件板卡本体上；

所述修复模块还进一步包括：

第二判断子模块，用于当发生异常事件的通信组件为单个硬件板卡本体或硬件板卡物理实体时，判断所述通信组件是否可以隔离；

第二隔离子模块，用于若所述第二判断子模块判断结果为是，则对所述通信组件进行隔离；

第二硬件重启子模块，用于若所述第二判断子模块判断结果为否，则重启所述通信组件的物理板卡本体或硬件板卡物理实体所在硬件板卡本体。

13.根据权利要求11或12所述的方法，其特征在于，所述修复模块还进一步包括：

连通性检测子模块，用于当发生异常事件的通信组件包括：至少一个呼叫逻辑实体，和/或，硬件板卡本体，和/或，硬件板卡物理实体时，对通信组件进行连通性检测；

第三判断子模块，用于判断联通性检测失败的通信组件是否可以隔离；

第三隔离子模块，用于若所述第三判断子模块的判断结果为是，则对所述联通性检测失败的通信组件进行隔离；

第三硬件重启子模块，用于若所述第三判断子模块的判断结果为否，或，若隔离所述联通性检测失败的通信组件后，异常事件仍然存在；则重启所述联通性检测失败的通信组件中的硬件板卡本体，和/或，呼叫逻辑实体所在的硬件板卡本体，和/或，硬件板卡物理实体所在的物理板卡本体；

上报警告子模块，用于若重启后，异常事件仍然存在，则上报告警进行人力干预。

14.根据权利要求10所述的装置，其特征在于，所述阈值包括：静态阈值和动态阈值；

所述静态阈值用于判断不随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障；

所述动态阈值用于判断随时间周期变化的控制面关键指标KPI或业务面关键指标KPI所对应的故障通信组件是否发生隐形故障。