探讨人工智能在通信网络故障溯源方面的应用研究

探讨人工智能在通信网络故障溯源方面的应用研究

1

概述

本文以人工智能技术为基础，结合现有网络运维技术，提出故障溯源整体解决方案。希望通过对告警信息进行合适的过滤、筛选、匹配、分类等流程确认告警信息，并根据各个告警之间的关系来进行告警溯源，屏蔽不重要或衍生的告警，实现对网络故障的快速诊断。同时配合相应的通信业务模型和网络拓扑结构实现故障的精准定位。最后通过实践中的具体案例分析，给出人工智能应用于网络故障溯源的结论和展望。

2

国内外研究现状

3

故障溯源相关应用场景研究

3.1 场景1：瞬断告警

瞬断告警定义为告警的发生时间和清除时间很短，小于一定的阈值。这类告警因为生命周期比较短，对运维人员没有太大的价值，而且会导致告警量激增，从而掩盖真正需要关注的告警，增加运维人员识别难度。

3.2 场景2：频发告警

如果一定时间内发生的相同告警/事件达到一定的数目，可以认为这些告警/事件之间存在一定的相关性。通过设置告警/事件频次分析规则，当某一段时间内发生的设定告警/事件的数目超过了预先设置的阈值，则认为这些告警/事件之间存在相关性。如同一网元同一单板的单板温度过高或过低告警X分钟出现Y次，合并生成一条新告警，说明单板温度异常。

3.3 场景3：同网元内故障影响分析

指同一网元内某物理对象（单板、拓扑）上产生告警会导致该网元上其他物理对象和逻辑对象产生关联告警。

▲图1 某同网元内故障示意图

3.4 场景4：同专业网上下层业务故障影响分析

该场景体现为因为某一个故障导致大面积告警的现象，需要快速地获取故障原因。如图2所示，服务层告警会导致客户层告警的发生，如光纤出现断点，光纤所在端口会报LOS告警，导致上层的 TMS、隧道、伪线、业务都上报告警，此时光纤所在端口的LOS告警就是根告警。

▲图2 某同专业网上下层业务故障示意图

3.5 场景5：跨专业网告警分析

▲图3 某跨专业网故障示意图

3.6 场景6：综合故障诊断

比如网络升级后，某LTE业务不通，如图4所示的流程，根据经验，查看监控数据，进行各种诊断动作和配置检查，从而定位故障点，告警只是分析的一部分。

▲图4 某综合故障分析过程流程图

4

第3章所述业务场景要解决的问题就是如何智能地识别故障并做有效分析，故障分析模型是基于关联规则，而关联规则通常使用关联分析算法得到。

关联规则算法是从一个数据集中发现项与项之间的隐藏关系。只有从多个不同的维度分析告警数据，才能识别出它们之间的关联关系，如告警发生的模式或规律。

基于人工智能的故障诊断和溯源就是在结合大数据关联规则分析及人工智能技术的基础上，根据系统中的网络、业务上下游关系，综合所有监控数据（包括告警、性能）、操作日志以及故障解决历史记录，输出故障特征与故障原因之间的一系列规则。本方案旨在采用人工智能和大数据挖掘技术，研究开发智能故障诊断系统（见图 5）。在实际网络运维中，根据故障特征自动匹配诊断规则进行诊断，自动得出故障点及相关处理建议。

▲图5 智能故障诊断系统示意图

本文所提出的智能故障诊断系统要先基于AI学习生成诊断规则库，然后根据规则进行故障分析。

4.1 基于AI学习生成诊断规则库

4.1.1 诊断信息获取

诊断信息越丰富，诊断效果越好，所以系统应具有自动获取整个周期（当前、历史）的网络状态信息的功能。即在现网运行中，除了记录操作日志、告警、KPI、故障处理建议这种日常监控数据外，对于网络拓扑、业务配置、业务状态这些只记录当前状态的数据，也要定时采样，作为学习的素材。

4.1.2 建立自学习能力

提取故障特征，比如PWE3-CES的包丢失表示2G业务不通，分析其附近的KPI、操作日志、丢包情况、业务配置，业务状态等信息，获取故障特征。此处可使用数据降维，分类算法。

分析足够多的案例，得到所有可能的原因，并计算原因概率。此处可使用概率论的相关算法。

4.2 诊断规则的运行

现网监控：实时监控告警，并且对流量、丢包情况定时采样，并记录操作日志。

匹配故障特征，进行故障诊断：对现网监控数据实时进行匹配，一旦匹配成功，立即开始诊断。将故障的原因按概率从大到小排序，逐个诊断，当确认某个原因存在时，就可以定位故障并给出处理建议。

故障修复确认，反向修正诊断规则库：故障在自动恢复或派单修复后，反馈派单中原因是否有效，修正诊断规则库的原因概率。

相比传统的故障溯源方案，本方案结合运维中的多种数据源，包括并不限于告警、性能、拓扑资源、日志以及侦测命令，这使本方案溯源结果更加精确，并且更具有可参考性。

5

中国联通IPRAN告警智能化分析识别

5.1 案例背景和目的

IPRAN网络主要用于承载3G/4G移动业务以及大客户专线业务，主要采用IP/MPLS动态协议技术。IP RAN网络协议以及网络的逻辑连接的复杂性，使IPRAN网管系统每天接收到大量的设备告警消息，其中很多告警信息都是由根源告警信息引起。

目前处理告警数据的相关规则多依赖于专家经验，通过规则过滤掉不关键的告警信息。这种方法的缺点是过滤能力有限且有些规则无法被发现。

因此需要将人工智能技术应用于IPRAN网络告警根因溯源中，形成更高效的告警处理方法。

5.2 方案和效果分析

故障是产生告警的根本原因，当网络发生故障时，将产生大量告警，挖掘告警之间的关联规则对故障定位有着重要意义。总体方案思路如图6所示。

▲ 图6 告警根因溯源技术方案流程图

该方案流程总体可分为以下4个步骤。

a）数据预处理阶段，包括数据导入和清洗、用户端侧告警匹配、频发告警识别。输入数据为现网提取的历史告警数据、网络拓扑数据和业务数据3种，经过清洗和整合转变为可处理的数据格式。用户端侧告警匹配是根据以往运维经验去除不关心/无价值的告警。频发告警的具体描述见第3章中的场景2定义，该类告警的处理方式为对同一端口上连续10s内的相同告警进行压缩，仅留下频发告警的第1条告警，其他均标识为可过滤告警。

b）关联规则挖掘阶段，该部分核心算法为 Prefix-Span时间序列模式挖掘算法［8］。与Apriori、序列模式、时空模式等挖掘算法相比，该算法更适合本案例。但传统的 PrefixSpan 算法挖掘出来的规则不带有约束条件，导致专家也无法判断关联规则的正确性，如规则A［光模块不可用告警→ RRU 断链告警］。为解决该问题，改进了 PrefixSpan算法，这使其挖掘过程存在约束条件。此时规则A改进为［光模块不可用告警→ RRU断链告警，同网元］，提升了算法规则挖掘的精确度。

c）关联规则确认与入库，其中包括已确认关联规则库和黑名单。通过多位专家确认上一步中挖掘出来的告警关联规则，将正确的规则存入已确认关联规则库中，以支撑下一步的告警识别工作。错误和不合理的规则自动导入黑名单，防止下次挖掘出同类规则。

d）根告警识别阶段，即给每个告警分别打上根告警、衍生告警、普通告警3种标签。根据8类不同约束条件对当前告警进行识别处理，约束条件分别为同一端口、同一网元、对应业务网元、同一业务ID关联、直连对端网元、直连对端端口、同环网元、对应业务ID关联。

由于厂商和地域的差异性，目前还无法建立统一适用的关联规则数据库。现已建立了A设备商IPRAN的告警关联规则知识库，共计198条规则。通过已建立的知识库，在多个城市进行了试点，表1为相关告警分析的结果。

从表1中可以看到B市和D市处理效果较差，冗余告警（用户侧、频发、衍生）过滤百分比为81%左右，C市和A市结果较好，最高可达98%。产生该结果的原因有2方面：一是由于告警总数不同，其中无关联的普通告警数量也不同；二是地域的差异性，B市和D市的传输网络设备更多，无法根据人工规则去除无关告警。

表1 多个试点城市的历史网络告警分析处理结果

为了更直观查看告警之间存在的拓扑及业务关联关系，系统可根据分析结果自动呈现告警关联分析拓扑图，通过不同颜色标记网元以区分根告警和衍生告警，并可通过查看历史告警、网元、端口等信息，辅助支撑运维人员更准确地定位故障、精准派单。

6

总结和展望

通过案例分析可以看出将人工智能技术引用到网络运维的故障溯源场景中是可行且有效的，基于运维数据智能化地识别告警之间的关联规则，解决了人工经验积累不足的问题，提升了运维效率。但现阶段仍存在一些问题，由于目前采用的是单一的数据挖掘算法，需要人工判断关联规则和结果是否正确，准确率和实时性仍无法保障，并未做到真正的智能。

为解决单一人工智能方法的不足，未来可采用多种诊断技术协同的新模式，即多智能体技术。基于多种具备不同功能的软件系统，将复杂的网络告警分解成单一、独立的成分和因素，各个系统协同合作，能整合包括网络状态信息、硬件信息、工单信息等更多的数据，实现自主学习、自主训练，不断提升系统性能，全面关联网络告警，准确定位网络故障。