劉思平 李冶文

（1 中國移動通信集團(tuán)設(shè)計(jì)院有限公司 北京 100080)

(2 中國移動通信集團(tuán)公司 北京 100032）

1 概述

一個(gè)單一的網(wǎng)絡(luò)故障會導(dǎo)致在時(shí)間、空間上產(chǎn)生大量的告警。在一個(gè)大而復(fù)雜的網(wǎng)絡(luò)中，有時(shí)候會同時(shí)出現(xiàn)多個(gè)網(wǎng)絡(luò)故障，這就會導(dǎo)致上層網(wǎng)管被海量告警所淹沒。這將會浪費(fèi)巨大運(yùn)維人力且導(dǎo)致運(yùn)維效率降低。在3GPP網(wǎng)絡(luò)管理規(guī)范中，引入了一種基于規(guī)則的告警壓縮模型：3GPP先進(jìn)告警管理（AAM，Advanced Alarm Management），可由網(wǎng)絡(luò)維護(hù)人員根據(jù)不同情況制定規(guī)則，從而屏蔽掉大量不必要的告警，或者合并相關(guān)告警。此模型的應(yīng)用將大為減少冗余告警，不僅會降低運(yùn)維成本，而且會提高網(wǎng)絡(luò)運(yùn)維的精細(xì)化，具有很大的應(yīng)用前景。

以前，針對這些海量告警，3GPP通過通知集成參考點(diǎn)（NotificationIRP）和告警集成參考點(diǎn)（AlarmIRP）將告警上報(bào)給上層網(wǎng)管（IRPManager）。集成參考點(diǎn)（IRP）是3GPP的術(shù)語，每一個(gè)集成參考點(diǎn)可以認(rèn)為是IRPAgent（被管網(wǎng)絡(luò)的代理）上的一個(gè)功能點(diǎn)，它可以被IRPManager調(diào)用，完成特定業(yè)務(wù)功能。圖1描述了這種告警上報(bào)場景。“1, 2.. 6”表示6個(gè)告警。這些告警均會記入IRPAgent日志，同時(shí)進(jìn)入AlarmIRP告警列表（AlarmList）。NotificationIRP激活了過濾器：F1。在這種場景下，IRPManager將收到“1, 3”告警，而“2, 4, 5, 6”被NotificationIRP的過濾器F1屏蔽掉了。

圖1 無AAM的告警上報(bào)

上述方式，只能通過NotificationIRP有限的過濾功能來處理海量告警情況，而不能進(jìn)行特別的告警壓縮，例如若某一告警重復(fù)出現(xiàn)，過濾器就無能為力了。為了解決這個(gè)問題，就必須引入一種模型，使得IRP Manager能夠控制IRPAgent,使得IRPAgent按要求（某種規(guī)則）傳遞告警。3GPP在過濾器基礎(chǔ)上，設(shè)計(jì)了先進(jìn)告警管理集成參考點(diǎn)來解決這個(gè)問題。AAM集成參考點(diǎn)的核心是：AAM規(guī)則，也就是IRPManager控制IRPAgent如何上報(bào)告警的某種特定要求。

圖2描述了設(shè)定了某個(gè)AAM規(guī)則的告警上報(bào)場景。同圖1，“1, 2…6”表示6個(gè)告警，且均會被記入日志。與圖1不同的是，由于AAM規(guī)則：R1的存在，“1, 2…6”輸出為兩個(gè)重要告警：A和B。A和B會出現(xiàn)在告警列表中，繼而通過NotificationIRP發(fā)送給IRPManagers。但是由于NotificationIRP過濾器的作用，最終只有A被IRPManagers收到，而B被NotificationIRP過濾器：F2屏蔽掉了。

圖2 有AAM的告警上報(bào)

圖2的示例要注意兩點(diǎn)，一個(gè)是重要告警，這是3GPP AAM規(guī)則中的一個(gè)重要概念，下面會介紹。另外一個(gè)是，IRPManager收到的告警不一定與IRPAgent收到的告警完全一一對應(yīng)，例如IRPAgent上 的 告 警 名 為 ：“1, 2…6”， 而 最 終 IRPManager收到的是名為A的告警。由此可見，IRPAgent會根據(jù)AAM規(guī)則，將相關(guān)告警進(jìn)行轉(zhuǎn)換再發(fā)送給IRPManager。

2 AAM規(guī)則原理

2.1 概念

一個(gè)告警對應(yīng)一個(gè)告警產(chǎn)生事件（event）、一個(gè)告警清除事件，可能對應(yīng)零個(gè)或者多個(gè)告警變更事件。告警產(chǎn)生事件的時(shí)間成為該告警的發(fā)生時(shí)間，告警清除事件的時(shí)間對應(yīng)該告警的清除時(shí)間，告警變更時(shí)間對應(yīng)該告警的變更時(shí)間。在AAM規(guī)則下，告警是否上報(bào)，如何上報(bào)，決定了對應(yīng)改告警的這3種事件是否上報(bào)和上報(bào)時(shí)間，這3種時(shí)間的上報(bào)時(shí)間并不總是等于事件的產(chǎn)生時(shí)間的。

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

將網(wǎng)絡(luò)告警分成兩類：重要（significant）和不重要（insignificant）。IRPAgent不會上報(bào)不重要的告警，上報(bào)所有的重要告警。

相似告警（alike alarm），兩個(gè)告警被認(rèn)為相似（alike）的條件是：告警的各個(gè)屬性等于AAM規(guī)則的過濾器設(shè)定的告警發(fā)生網(wǎng)元或資源實(shí)例、告警類型、嚴(yán)重性級別、問題原因等。若不符合過濾器條件，則稱該告警不相似（not alike）。

時(shí)間窗口低端（lower edge of time window）：時(shí)間段的起始時(shí)間點(diǎn)。

時(shí)間窗口高端（upper edge of time window）：時(shí)間段的終止時(shí)間點(diǎn)。

2.2 AAM規(guī)則構(gòu)成要素

IRPManager通過定義AAM規(guī)則，使得告警產(chǎn)生、告警變更、告警清除事件按照重要、不重要進(jìn)行區(qū)分，重要的將會在北向接口上報(bào)，不重要的事件將不上報(bào)。

一個(gè)AAM規(guī)則由如下3個(gè)要素組成。

第1個(gè)要素：判定相似告警的過濾器。是一個(gè)判定標(biāo)準(zhǔn)，用于決策一個(gè)告警是否是相似告警。如果判定該告警為不相似，那么這個(gè)告警不會被規(guī)則再做進(jìn)一步處理。IRPManager可以設(shè)定AAM規(guī)則的過濾器。

第2個(gè)要素：相似告警的處理。這是判定重要告警的機(jī)制：此相似告警是重要告警，將被上報(bào)，或者此相似告警為不重要告警，將被壓縮掉（拋棄掉）。

當(dāng)一個(gè)重要告警被區(qū)分出來，算法將進(jìn)一步?jīng)Q定：決定此重要告警對應(yīng)的告警產(chǎn)生/告警變更/告警清除事件的上報(bào)時(shí)間和決定上報(bào)的告警產(chǎn)生/告警變更/告警清除事件中告警產(chǎn)生時(shí)間、告警變更時(shí)間、告警清除時(shí)間。

第3個(gè)組成要素名為：與日志和告警列表的關(guān)系。規(guī)定了哪些告警將會進(jìn)入IRPAgent的日志中，哪些告警會進(jìn)入告警集成參考點(diǎn)的告警列表中。告警進(jìn)入告警列表，也就意味著會被上傳到IRPManager。

3GPP定義了4種類型的AAM規(guī)則：門限規(guī)則（ThresholdRule）、 瞬時(shí)規(guī)則（TransientRule）、凍結(jié)規(guī)則（ToggleRule）、設(shè)備商自定義規(guī)則（VendorSpecificRule）。每種類型的第1個(gè)要素和第3個(gè)要素都是一樣的。待判定的告警事件相應(yīng)字段等于過濾器中的這些值，那么就認(rèn)為是相似的，否則認(rèn)為不相似。相似告警要進(jìn)入日志，重要告警進(jìn)入告警列表（進(jìn)入列表等同于要上報(bào)）。不同的在于判定重要告警，下面介紹規(guī)則的時(shí)候重點(diǎn)介紹這第2個(gè)要素。設(shè)備商可以自定義規(guī)則，制訂的規(guī)則只要符合上述3種規(guī)則的制訂形式即可，3GPP并沒有進(jìn)一步對這種自定義規(guī)則進(jìn)行約束，設(shè)備商可以自行定義。

2.3 AAM規(guī)則描述符號

描述每一類規(guī)則進(jìn)行舉例的時(shí)候，都用到了以下符號。粗的水平線意思是一條時(shí)間線。兩邊帶箭頭的虛線指時(shí)間窗口的低端和高端（圖3沒有標(biāo)出）?！?”盒子表示當(dāng)前待判定的告警。盒子的左端對應(yīng)告警產(chǎn)生時(shí)間，右端對應(yīng)告警清除時(shí)間，所以盒子的水平跨度就表示該告警的存活時(shí)間跨度。

圖3 示例圖符號：帶判定告警

如果是重要告警，就將被上報(bào)，這個(gè)上報(bào)的告警在時(shí)間線下用帶陰影的盒子表示，如圖4所示。盒子的左端表示相應(yīng)的告警通知發(fā)出的時(shí)間，這個(gè)發(fā)送時(shí)間不一定必須與告警產(chǎn)生/告警變更時(shí)間相等。 盒子右端表示相應(yīng)告警的告警清除事件的發(fā)送時(shí)間，這個(gè)時(shí)間不一定必須與告警清除事件中的告警清除時(shí)間相等。

圖4 示例圖符號：重要告警的發(fā)送

3 門限規(guī)則

3.1 屬性

本規(guī)則有3個(gè)參數(shù)，也即告警產(chǎn)生門限（下面簡稱N)，滑動時(shí)間窗口（下面簡稱T)和過濾器。

3.2 相似告警的處理

時(shí)間窗口低端的開始值是門限規(guī)則的激活時(shí)間，待判定告警事件將經(jīng)歷如下步驟。

（1）通過過濾器，驗(yàn)證是否是相似告警；

（2）若相似，那么T時(shí)間窗口的低端、高端、計(jì)數(shù)將重新賦值：T時(shí)間窗口的高端變成待判定告警左側(cè)；T時(shí)間窗口的低端要么等于當(dāng)前T時(shí)間窗口的低端，要么等于待判定告警左側(cè)與滑動時(shí)間窗口T的長度之差，選擇的原則是取時(shí)間最晚者（最靠右）；

（3）計(jì)數(shù)是時(shí)間窗口的低端、高端之間的告警數(shù)目（包含新告警）。若數(shù)目達(dá)到了門限N，那么該告警被認(rèn)為是重要的，并且將T時(shí)間窗口的低端置為待判定告警左側(cè)，計(jì)數(shù)歸0。

對于不上報(bào)的告警，不會有告警清除事件被發(fā)送。如果一個(gè)告警清除事件是關(guān)于一個(gè)在門限規(guī)則激活之前已經(jīng)發(fā)送給IRPManager的告警的，則不應(yīng)該被屏蔽掉。

若告警決定上報(bào)，那么它對應(yīng)的相關(guān)事件，都會立即上報(bào)。該告警的發(fā)生時(shí)間、變更時(shí)間和清除時(shí)間與其對應(yīng)的相似告警完全一致。

3.3 示例

由示例可以看出，門限規(guī)則適合于這樣的場景：某個(gè)告警只有重復(fù)出現(xiàn)N次，才能被作為重要告警上報(bào)，例如一個(gè)網(wǎng)路自愈告警，如果在N次以內(nèi)自愈都不成功，那么就會被作為重要告警上報(bào)。

圖5 門限規(guī)則示例——重要告警

4 瞬時(shí)規(guī)則

4.1 參數(shù)

本規(guī)則有兩個(gè)參數(shù)：最少存活分鐘數(shù)（下面簡稱T)和過濾器。

4.2 相似告警的處理

對于一個(gè)相似告警，如果其存活周期（告警產(chǎn)生和告警清除的時(shí)間差）小于T，那么就認(rèn)為它不重要，否則認(rèn)為其重要。對于不上報(bào)的告警，亦不會有告警清除事件被發(fā)送。如果告警事件與瞬時(shí)規(guī)則激活之前已經(jīng)發(fā)送給IRPManager的告警相關(guān)，則不應(yīng)該被屏蔽掉。

若告警決定上報(bào)，那么它對應(yīng)的相關(guān)事件，都會立即上報(bào)。該告警的發(fā)生時(shí)間、變更時(shí)間和清除時(shí)間與其對應(yīng)的相似告警完全一致。

4.3 示例

由示例可知，瞬時(shí)規(guī)則要解決的問題是如果一個(gè)告警在短時(shí)間內(nèi)就被清除了，那么將不會被上報(bào)，只要超過了最少存活分鐘數(shù)還沒有被清除才會被上報(bào)，這對于瞬時(shí)告警來說能起到屏蔽的作用。

圖6 瞬時(shí)規(guī)則示例-不重要告警

5 凍結(jié)規(guī)則

5.1 參數(shù)

本規(guī)則有4個(gè)參數(shù)：過濾器，告警發(fā)生門限（下面簡稱N)，凍結(jié)啟動窗口（下面簡稱T1)和凍結(jié)關(guān)閉窗口（下面簡稱T2)。

5.2 相似告警的處理

5.2.1 起始值

凍結(jié)啟動時(shí)間窗口和凍結(jié)關(guān)閉時(shí)間窗口的低端起始值是凍結(jié)規(guī)則的激活時(shí)間。計(jì)數(shù)的起始值是0。起始時(shí)候，所有的告警都認(rèn)為是“未凍結(jié)”。

5.2.2 對于相似告警的處理

當(dāng)一個(gè)告警產(chǎn)生/告警變更/告警清除事件通過了過濾器，凍結(jié)啟動時(shí)間窗口和凍結(jié)關(guān)閉時(shí)間窗口的低端、高端，以及計(jì)數(shù)將被重置：

（1）設(shè)定凍結(jié)啟動時(shí)間窗口：

*凍結(jié)啟動窗口高端置為待判定告警左側(cè)（即：“?”盒子最左端）；

*凍結(jié)啟動窗口低端置為待判定告警左側(cè)與T1之差。

（2）通過計(jì)數(shù)決定是否凍結(jié)：

*計(jì)數(shù)即在凍結(jié)啟動窗口低端和高端之間的相似告警的計(jì)數(shù)（包括待判定告警）；

*計(jì)數(shù)小于門限N的時(shí)候的每個(gè)告警事件都被認(rèn)為是重要的，立即上報(bào)。如圖7的T1時(shí)間線內(nèi)的告警就屬于這種情況。

如果計(jì)數(shù)大于或者等于門限N，并且該事件是告警產(chǎn)生事件，且狀態(tài)是“未凍結(jié)”，那么該告警將被上報(bào)，且將其狀態(tài)置為“凍結(jié)”。隨后所有的相似告警（告警產(chǎn)生/告警變更/告警清除事件）均被認(rèn)為不重要，直到某告警的狀態(tài)為“未凍結(jié)”。

（3）設(shè)定凍結(jié)關(guān)閉窗口：

*若告警的狀態(tài)是“未凍結(jié)”，那么無需設(shè)定凍結(jié)關(guān)閉窗口的低端和高端;

*若告警狀態(tài)是“凍結(jié)”，那么凍結(jié)關(guān)閉時(shí)間窗口的高端置為待判定告警左側(cè)與T2時(shí)間之和。凍結(jié)關(guān)閉時(shí)間窗口的低端置為待判定告警左側(cè)。

5.2.3 返回到“未凍結(jié)”狀態(tài)

若時(shí)間到達(dá)凍結(jié)關(guān)閉時(shí)間窗口的高端，那么告警將被認(rèn)為是“未凍結(jié)”狀態(tài)，也即相似告警將被認(rèn)為是重要的。

若最后的事件是告警變更或者告警清除，那么返回到“未凍結(jié)”狀態(tài)將會觸發(fā)相關(guān)事件被發(fā)送，這樣就解決了一系列相同告警的第一個(gè)告警產(chǎn)生事件有對應(yīng)的告警清除或者告警變更事件上報(bào)。

但是何時(shí)上報(bào)這個(gè)告警清除事件呢？告警清除事件的發(fā)送時(shí)間，如果告警清除時(shí)間早于告警發(fā)生時(shí)間與T2之和，那么該通知應(yīng)該在最后一個(gè)相似告警的告警清除時(shí)間與T2時(shí)間之和之后立即發(fā)送，如圖7所示。如果告警清除時(shí)間晚于或者等于告警發(fā)生時(shí)間與T2之和，那么該事件應(yīng)該在最后一個(gè)相似告警的告警清除時(shí)間后立即發(fā)送。

在“凍結(jié)”期間，變更告警將會判定為不重要而被屏蔽掉。

除開上述不同之外，重要告警相關(guān)事件的發(fā)送時(shí)間，及其中時(shí)間參數(shù)的值，與門限規(guī)則、瞬時(shí)規(guī)則相同。

5.3 示例

凍結(jié)規(guī)則適用于使得運(yùn)營商擺脫那些告警重復(fù)出現(xiàn)的情況，例如某設(shè)備處于倒換狀態(tài)，某些告警將會重復(fù)出現(xiàn)。

在這種情況下，在T1時(shí)間段內(nèi)，相同的告警產(chǎn)生/告警清除事件，都會認(rèn)為是重要的并且立即上報(bào)。但是到了門限N的容忍限度，那么IRPAgent將只上報(bào)告警產(chǎn)生事件，然后置于凍結(jié)狀態(tài)，所有后續(xù)告警事件均被屏蔽，直到T2時(shí)間段過去，才轉(zhuǎn)到非凍結(jié)狀態(tài)，后續(xù)告警事件判定為重要，這個(gè)時(shí)候收到的告警變更事件和告警清除事件就成為了之前最后一個(gè)告警產(chǎn)生事件對應(yīng)的清除和變更事件，也就是說，一系列告警被連接成了一個(gè)告警上報(bào)。

圖7 凍結(jié)規(guī)則示例

5.4 異常處理

凍結(jié)規(guī)則作用是將一系列相似告警合并為一個(gè)重要告警上報(bào)。但在凍結(jié)期間，丟失了一系列告警中某告警的清除事件，則會造成這個(gè)重要告警不能被清除，也就是無法上報(bào)這個(gè)告警的清除時(shí)間，造成該告警無法關(guān)閉。處理這種異常的方法在參考文獻(xiàn)2進(jìn)行了描述，在此不贅述。

6 小結(jié)

AAM規(guī)則可以使得網(wǎng)絡(luò)運(yùn)營商把上報(bào)的告警數(shù)量降低到一個(gè)合理、可管理的級別。規(guī)則依賴于告警類型、環(huán)境、發(fā)生時(shí)刻等諸多因素，規(guī)則制定需要仔細(xì)考慮，以免把本來重要的告警作為不重要的告警篩選出去。

目前通信網(wǎng)絡(luò)管理系統(tǒng)缺乏一個(gè)有效的告警壓縮機(jī)制，且國內(nèi)外尚無成熟的告警壓縮機(jī)制的理論研究和應(yīng)用實(shí)現(xiàn)。3GPP告警壓縮模型正好填補(bǔ)了這方面的空白，國內(nèi)網(wǎng)絡(luò)運(yùn)營商、設(shè)備制造商、網(wǎng)管開發(fā)商以及學(xué)術(shù)界尚未對本模型有相應(yīng)的研究論文和應(yīng)用實(shí)例。從本文的分析來看，它具有很大的應(yīng)用前景，必將大為降低網(wǎng)絡(luò)運(yùn)維成本，提高網(wǎng)絡(luò)運(yùn)維精細(xì)化程度。更重要的是，由于支持設(shè)備商自定義規(guī)則，這就為解決與告警處理相關(guān)的諸多需求（例如告警關(guān)聯(lián)）提供了基礎(chǔ)的解決機(jī)制。

[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)