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)