3GPP先进告警管理介绍

刘思平 李冶文

（1 中国移动通信集团设计院有限公司 北京 100080)

(2 中国移动通信集团公司 北京 100032）

1 概述

一个单一的网络故障会导致在时间、空间上产生大量的告警。在一个大而复杂的网络中，有时候会同时出现多个网络故障，这就会导致上层网管被海量告警所淹没。这将会浪费巨大运维人力且导致运维效率降低。在3GPP网络管理规范中，引入了一种基于规则的告警压缩模型：3GPP先进告警管理（AAM，Advanced Alarm Management），可由网络维护人员根据不同情况制定规则，从而屏蔽掉大量不必要的告警，或者合并相关告警。此模型的应用将大为减少冗余告警，不仅会降低运维成本，而且会提高网络运维的精细化，具有很大的应用前景。

以前，针对这些海量告警，3GPP通过通知集成参考点（NotificationIRP）和告警集成参考点（AlarmIRP）将告警上报给上层网管（IRPManager）。集成参考点（IRP）是3GPP的术语，每一个集成参考点可以认为是IRPAgent（被管网络的代理）上的一个功能点，它可以被IRPManager调用，完成特定业务功能。图1描述了这种告警上报场景。“1, 2.. 6”表示6个告警。这些告警均会记入IRPAgent日志，同时进入AlarmIRP告警列表（AlarmList）。NotificationIRP激活了过滤器：F1。在这种场景下，IRPManager将收到“1, 3”告警，而“2, 4, 5, 6”被NotificationIRP的过滤器F1屏蔽掉了。

图1 无AAM的告警上报

上述方式，只能通过NotificationIRP有限的过滤功能来处理海量告警情况，而不能进行特别的告警压缩，例如若某一告警重复出现，过滤器就无能为力了。为了解决这个问题，就必须引入一种模型，使得IRP Manager能够控制IRPAgent,使得IRPAgent按要求（某种规则）传递告警。3GPP在过滤器基础上，设计了先进告警管理集成参考点来解决这个问题。AAM集成参考点的核心是：AAM规则，也就是IRPManager控制IRPAgent如何上报告警的某种特定要求。

图2描述了设定了某个AAM规则的告警上报场景。同图1，“1, 2…6”表示6个告警，且均会被记入日志。与图1不同的是，由于AAM规则：R1的存在，“1, 2…6”输出为两个重要告警：A和B。A和B会出现在告警列表中，继而通过NotificationIRP发送给IRPManagers。但是由于NotificationIRP过滤器的作用，最终只有A被IRPManagers收到，而B被NotificationIRP过滤器：F2屏蔽掉了。

图2 有AAM的告警上报

图2的示例要注意两点，一个是重要告警，这是3GPP AAM规则中的一个重要概念，下面会介绍。另外一个是，IRPManager收到的告警不一定与IRPAgent收到的告警完全一一对应，例如IRPAgent上 的 告 警 名 为 ：“1, 2…6”， 而 最 终 IRPManager收到的是名为A的告警。由此可见，IRPAgent会根据AAM规则，将相关告警进行转换再发送给IRPManager。

2 AAM规则原理

2.1 概念

一个告警对应一个告警产生事件（event）、一个告警清除事件，可能对应零个或者多个告警变更事件。告警产生事件的时间成为该告警的发生时间，告警清除事件的时间对应该告警的清除时间，告警变更时间对应该告警的变更时间。在AAM规则下，告警是否上报，如何上报，决定了对应改告警的这3种事件是否上报和上报时间，这3种时间的上报时间并不总是等于事件的产生时间的。

AAM引入了以下一些新概念。

将网络告警分成两类：重要（significant）和不重要（insignificant）。IRPAgent不会上报不重要的告警，上报所有的重要告警。

相似告警（alike alarm），两个告警被认为相似（alike）的条件是：告警的各个属性等于AAM规则的过滤器设定的告警发生网元或资源实例、告警类型、严重性级别、问题原因等。若不符合过滤器条件，则称该告警不相似（not alike）。

时间窗口低端（lower edge of time window）：时间段的起始时间点。

时间窗口高端（upper edge of time window）：时间段的终止时间点。

2.2 AAM规则构成要素

IRPManager通过定义AAM规则，使得告警产生、告警变更、告警清除事件按照重要、不重要进行区分，重要的将会在北向接口上报，不重要的事件将不上报。

一个AAM规则由如下3个要素组成。

第1个要素：判定相似告警的过滤器。是一个判定标准，用于决策一个告警是否是相似告警。如果判定该告警为不相似，那么这个告警不会被规则再做进一步处理。IRPManager可以设定AAM规则的过滤器。

第2个要素：相似告警的处理。这是判定重要告警的机制：此相似告警是重要告警，将被上报，或者此相似告警为不重要告警，将被压缩掉（抛弃掉）。

当一个重要告警被区分出来，算法将进一步决定：决定此重要告警对应的告警产生/告警变更/告警清除事件的上报时间和决定上报的告警产生/告警变更/告警清除事件中告警产生时间、告警变更时间、告警清除时间。

第3个组成要素名为：与日志和告警列表的关系。规定了哪些告警将会进入IRPAgent的日志中，哪些告警会进入告警集成参考点的告警列表中。告警进入告警列表，也就意味着会被上传到IRPManager。

3GPP定义了4种类型的AAM规则：门限规则（ThresholdRule）、 瞬时规则（TransientRule）、冻结规则（ToggleRule）、设备商自定义规则（VendorSpecificRule）。每种类型的第1个要素和第3个要素都是一样的。待判定的告警事件相应字段等于过滤器中的这些值，那么就认为是相似的，否则认为不相似。相似告警要进入日志，重要告警进入告警列表（进入列表等同于要上报）。不同的在于判定重要告警，下面介绍规则的时候重点介绍这第2个要素。设备商可以自定义规则，制订的规则只要符合上述3种规则的制订形式即可，3GPP并没有进一步对这种自定义规则进行约束，设备商可以自行定义。

2.3 AAM规则描述符号

描述每一类规则进行举例的时候，都用到了以下符号。粗的水平线意思是一条时间线。两边带箭头的虚线指时间窗口的低端和高端（图3没有标出）。“?”盒子表示当前待判定的告警。盒子的左端对应告警产生时间，右端对应告警清除时间，所以盒子的水平跨度就表示该告警的存活时间跨度。

图3 示例图符号：带判定告警

如果是重要告警，就将被上报，这个上报的告警在时间线下用带阴影的盒子表示，如图4所示。盒子的左端表示相应的告警通知发出的时间，这个发送时间不一定必须与告警产生/告警变更时间相等。 盒子右端表示相应告警的告警清除事件的发送时间，这个时间不一定必须与告警清除事件中的告警清除时间相等。

图4 示例图符号：重要告警的发送

3 门限规则

3.1 属性

本规则有3个参数，也即告警产生门限（下面简称N)，滑动时间窗口（下面简称T)和过滤器。

3.2 相似告警的处理

时间窗口低端的开始值是门限规则的激活时间，待判定告警事件将经历如下步骤。

（1）通过过滤器，验证是否是相似告警；

（2）若相似，那么T时间窗口的低端、高端、计数将重新赋值：T时间窗口的高端变成待判定告警左侧；T时间窗口的低端要么等于当前T时间窗口的低端，要么等于待判定告警左侧与滑动时间窗口T的长度之差，选择的原则是取时间最晚者（最靠右）；

（3）计数是时间窗口的低端、高端之间的告警数目（包含新告警）。若数目达到了门限N，那么该告警被认为是重要的，并且将T时间窗口的低端置为待判定告警左侧，计数归0。

对于不上报的告警，不会有告警清除事件被发送。如果一个告警清除事件是关于一个在门限规则激活之前已经发送给IRPManager的告警的，则不应该被屏蔽掉。

若告警决定上报，那么它对应的相关事件，都会立即上报。该告警的发生时间、变更时间和清除时间与其对应的相似告警完全一致。

3.3 示例

由示例可以看出，门限规则适合于这样的场景：某个告警只有重复出现N次，才能被作为重要告警上报，例如一个网路自愈告警，如果在N次以内自愈都不成功，那么就会被作为重要告警上报。

图5 门限规则示例——重要告警

4 瞬时规则

4.1 参数

本规则有两个参数：最少存活分钟数（下面简称T)和过滤器。

4.2 相似告警的处理

对于一个相似告警，如果其存活周期（告警产生和告警清除的时间差）小于T，那么就认为它不重要，否则认为其重要。对于不上报的告警，亦不会有告警清除事件被发送。如果告警事件与瞬时规则激活之前已经发送给IRPManager的告警相关，则不应该被屏蔽掉。

若告警决定上报，那么它对应的相关事件，都会立即上报。该告警的发生时间、变更时间和清除时间与其对应的相似告警完全一致。

4.3 示例

由示例可知，瞬时规则要解决的问题是如果一个告警在短时间内就被清除了，那么将不会被上报，只要超过了最少存活分钟数还没有被清除才会被上报，这对于瞬时告警来说能起到屏蔽的作用。

图6 瞬时规则示例-不重要告警

5 冻结规则

5.1 参数

本规则有4个参数：过滤器，告警发生门限（下面简称N)，冻结启动窗口（下面简称T1)和冻结关闭窗口（下面简称T2)。

5.2 相似告警的处理

5.2.1 起始值

冻结启动时间窗口和冻结关闭时间窗口的低端起始值是冻结规则的激活时间。计数的起始值是0。起始时候，所有的告警都认为是“未冻结”。

5.2.2 对于相似告警的处理

当一个告警产生/告警变更/告警清除事件通过了过滤器，冻结启动时间窗口和冻结关闭时间窗口的低端、高端，以及计数将被重置：

（1）设定冻结启动时间窗口：

*冻结启动窗口高端置为待判定告警左侧（即：“?”盒子最左端）；

*冻结启动窗口低端置为待判定告警左侧与T1之差。

（2）通过计数决定是否冻结：

*计数即在冻结启动窗口低端和高端之间的相似告警的计数（包括待判定告警）；

*计数小于门限N的时候的每个告警事件都被认为是重要的，立即上报。如图7的T1时间线内的告警就属于这种情况。

如果计数大于或者等于门限N，并且该事件是告警产生事件，且状态是“未冻结”，那么该告警将被上报，且将其状态置为“冻结”。随后所有的相似告警（告警产生/告警变更/告警清除事件）均被认为不重要，直到某告警的状态为“未冻结”。

（3）设定冻结关闭窗口：

*若告警的状态是“未冻结”，那么无需设定冻结关闭窗口的低端和高端;

*若告警状态是“冻结”，那么冻结关闭时间窗口的高端置为待判定告警左侧与T2时间之和。冻结关闭时间窗口的低端置为待判定告警左侧。

5.2.3 返回到“未冻结”状态

若时间到达冻结关闭时间窗口的高端，那么告警将被认为是“未冻结”状态，也即相似告警将被认为是重要的。

若最后的事件是告警变更或者告警清除，那么返回到“未冻结”状态将会触发相关事件被发送，这样就解决了一系列相同告警的第一个告警产生事件有对应的告警清除或者告警变更事件上报。

但是何时上报这个告警清除事件呢？告警清除事件的发送时间，如果告警清除时间早于告警发生时间与T2之和，那么该通知应该在最后一个相似告警的告警清除时间与T2时间之和之后立即发送，如图7所示。如果告警清除时间晚于或者等于告警发生时间与T2之和，那么该事件应该在最后一个相似告警的告警清除时间后立即发送。

在“冻结”期间，变更告警将会判定为不重要而被屏蔽掉。

除开上述不同之外，重要告警相关事件的发送时间，及其中时间参数的值，与门限规则、瞬时规则相同。

5.3 示例

冻结规则适用于使得运营商摆脱那些告警重复出现的情况，例如某设备处于倒换状态，某些告警将会重复出现。

在这种情况下，在T1时间段内，相同的告警产生/告警清除事件，都会认为是重要的并且立即上报。但是到了门限N的容忍限度，那么IRPAgent将只上报告警产生事件，然后置于冻结状态，所有后续告警事件均被屏蔽，直到T2时间段过去，才转到非冻结状态，后续告警事件判定为重要，这个时候收到的告警变更事件和告警清除事件就成为了之前最后一个告警产生事件对应的清除和变更事件，也就是说，一系列告警被连接成了一个告警上报。

图7 冻结规则示例

5.4 异常处理

冻结规则作用是将一系列相似告警合并为一个重要告警上报。但在冻结期间，丢失了一系列告警中某告警的清除事件，则会造成这个重要告警不能被清除，也就是无法上报这个告警的清除时间，造成该告警无法关闭。处理这种异常的方法在参考文献2进行了描述，在此不赘述。

6 小结

AAM规则可以使得网络运营商把上报的告警数量降低到一个合理、可管理的级别。规则依赖于告警类型、环境、发生时刻等诸多因素，规则制定需要仔细考虑，以免把本来重要的告警作为不重要的告警筛选出去。

目前通信网络管理系统缺乏一个有效的告警压缩机制，且国内外尚无成熟的告警压缩机制的理论研究和应用实现。3GPP告警压缩模型正好填补了这方面的空白，国内网络运营商、设备制造商、网管开发商以及学术界尚未对本模型有相应的研究论文和应用实例。从本文的分析来看，它具有很大的应用前景，必将大为降低网络运维成本，提高网络运维精细化程度。更重要的是，由于支持设备商自定义规则，这就为解决与告警处理相关的诸多需求（例如告警关联）提供了基础的解决机制。

[1]TS 32.121 Telecommunication Management; Advanced Alarm Management (AAM) Integration Reference Point (IRP): Requirements

[2]TS 32.122 Telecommunication Management; Advanced Alarm Management (AAM) Integration Reference Point (IRP); Information Service (IS)