本發(fā)明涉及通信領域，具體而言，涉及一種告警的處理方法及裝置。

背景技術：

移動通信網絡的告警管理模式是統(tǒng)一集中管理模式，圖1是相關技術中移動通信網絡告警管理圖，圖2是相關技術中基站告警上報到網管流程圖，如圖1和圖2所示，分布在不同地點的N個(幾百到幾千個)基站，統(tǒng)一將告警數據上報到位于監(jiān)控中心的網管，統(tǒng)一監(jiān)控。

網管收到了某個基站的告警后，首先需要將該告警記錄在網管硬盤上，然后還需要視情況自動產生工單(例如某告警持續(xù)了10分鐘，則自動產生一個工單)。正常情況下，告警產生后，持續(xù)較長時間或一直持續(xù)，網管會派一個此告警的工單，通知維護人員上站處理，處理完成后，告警消失，工單關閉。但某些告警不是這樣的，會反復地發(fā)生，反復上報網管，例如，GPS饋線輕微短路，會導致反復上報GPS短路告警，又例如，有的位于娛樂場所的RRU使用照明電供電，導致每天晚上物業(yè)關電時，基站也上報一次RRU斷電告警。

這些反復告警，本文稱之為頻閃告警，或者抖動告警，除了導致網管占用很大硬盤空間用以記錄，還導致有時一直派不出工單，即每次告警持續(xù)時間很短，尚未派單就恢復了，或者有時反復派單，即上一次派單了，有關人員尚未來得及上站處理，告警又恢復了，接著又告警發(fā)生，又派單。

查詢相關技術中有關與告警處理的專利文獻有：

第一篇：公開/公告號：CN101014179，公開/公告日期：2007.08.08，名稱：一種通信系統(tǒng)中告警防抖的實現裝置和實現方法。該專利的方法是，預定時間內告警次數超過門限，則上報的告警不恢復，預定時間內告警不再發(fā)生，則上報恢復。

第二篇：公開/公告號：CN101917303A，公開/公告日期：2010.12.15，名稱：告警防抖動的處理方法及裝置。該專利的方法是，通過預測試獲取設備的告警產生與恢復之間的時間間隔權值T，比較時間間隔權值T和設備的預定的標準時間間隔W的大小，并根據T和W的大小關系確定所采用的告警抖動處理策略。

可見，相關技術中對于告警的處理具有缺點如下：(1)不適合周期較長的反復告警(幾十分鐘或幾個小時或一天或幾天才發(fā)生一次的周期告警)；(2)一般只能對常見抖動告警設置；(3)用戶在網管看到的告警都是一樣的，不知道哪些是一直持續(xù)的告警， 哪些是抖動的告警；(4)用戶從其它途徑知道是抖動告警了，也不知道抖動的規(guī)律，排障很不方。

針對相關技術中難以區(qū)分告警的抖動規(guī)律的問題，目前尚未存在有效的解決方案。

技術實現要素：

本發(fā)明提供了一種告警的處理方法及裝置，以至少解決相關技術中難以區(qū)分告警的抖動規(guī)律的問題。

根據本發(fā)明的一個方面，提供了一種告警的處理方法，包括：統(tǒng)計預定時間段內已產生告警中頻閃告警的信息，其中，所述頻閃告警為周期性產生的告警，所述頻閃告警的信息包括：所述頻閃告警的類型、產生所述頻閃告警的平均周期、所述平均周期中正常平均持續(xù)時間、所述平均周期中告警平均持續(xù)時間；上報所述頻閃告警的信息；在經過指定時間段后所述頻閃告警未產生時，上報用于指示所述頻閃告警恢復的信息，其中，所述指定時間段為所述正常平均持續(xù)時間的整數倍。

進一步地，在統(tǒng)計預定時間段內已產生告警中頻閃告警的信息之前，所述方法還包括：預先配置所述頻閃告警平均周期的閾值范圍。

進一步地，在統(tǒng)計預定時間段內已產生告警中頻閃告警的信息之后，所述方法還包括：上報不在所述閾值范圍內的非頻閃告警，或上報被設置為實時上報的頻閃告警。

進一步地，在上報用于指示所述頻閃告警恢復的信息之后，所述方法還包括：接收實時上報所述頻閃告警的指令；依據所述指令不對所述頻閃告警的信息進行統(tǒng)計，實時上報所述頻閃告警。

進一步地，所述頻閃告警包括：快閃告警和慢閃告警。

根據本發(fā)明的一個方面，提供了一種告警的處理裝置，包括：統(tǒng)計模塊，用于統(tǒng)計預定時間段內已產生告警中頻閃告警的信息，其中，所述頻閃告警為周期性產生的告警，所述頻閃告警的信息包括：所述頻閃告警的類型、產生所述頻閃告警的平均周期、所述平均周期中正常平均持續(xù)時間、所述平均周期中告警平均持續(xù)時間；第一上報模塊，用于上報所述頻閃告警的信息；第二上報模塊，用于在經過指定時間段后所述頻閃告警未產生時，上報用于指示所述頻閃告警恢復的信息，其中，所述指定時間段為所述正常平均持續(xù)時間的整數倍。

進一步地，在統(tǒng)計預定時間段內已產生告警中頻閃告警的信息之前，所述裝置還包括：配置模塊，用于預先配置所述頻閃告警平均周期的閾值范圍。

進一步地，在統(tǒng)計預定時間段內已產生告警中頻閃告警的信息之后，所述裝置還包括：第三上報模塊，用于上報不在所述閾值范圍內的非頻閃告警，或被設置為實時上報的頻閃告警。

進一步地，在上報用于指示所述頻閃告警恢復的信息之后，所述裝置還包括：接收模塊，用于接收實時上報所述頻閃告警的指令；第四上報模塊，用于依據所述指令不對所述頻閃告警的信息進行統(tǒng)計，實時上報所述頻閃告警。

進一步地，所述頻閃告警包括：快閃告警和慢閃告警。

在本發(fā)明中，采用基站統(tǒng)計預定時間段內已產生告警中周期性產生的頻閃告警的信息，而該信息包括：頻閃告警的類型、產生頻閃告警的平均周期、平均周期中正常平均持續(xù)時間、平均周期中告警平均持續(xù)時間；在統(tǒng)計完之后上報頻閃告警的信息到網管，通過該信息網管就能適時的對告警進行下單；而在經過預定時間后頻閃告警未產生時，基站上報用于指示頻閃告警恢復的信息到網管，其中，預定時間為正常平均持續(xù)時間的整數倍，從而解決了相關技術中難以區(qū)分告警的抖動規(guī)律的問題，提高了處理告警的效率。

附圖說明

此處所說明的附圖用來提供對本發(fā)明的進一步理解，構成本申請的一部分，本發(fā)明的示意性實施例及其說明用于解釋本發(fā)明，并不構成對本發(fā)明的不當限定。在附圖中：

圖1是相關技術中移動通信網絡告警管理圖；

圖2是相關技術中基站告警上報到網管流程圖；

圖3是根據本發(fā)明實施例的告警的處理方法的流程圖；

圖4是根據本發(fā)明實施例的告警的處理裝置的結構框圖；

圖5是根據本發(fā)明實施例的告警的處理裝置的可選結構框圖一；

圖6是根據本發(fā)明實施例的告警的處理裝置的可選結構框圖二；

圖7是根據本發(fā)明實施例的告警的處理裝置的可選結構框圖三；

圖8是根據本發(fā)明可選實施例的基站頻閃告警的上報方法流程圖。

具體實施方式

下文中將參考附圖并結合實施例來詳細說明本發(fā)明。需要說明的是，在不沖突的情況下，本申請中的實施例及實施例中的特征可以相互組合。

需要說明的是，本發(fā)明的說明書和權利要求書及上述附圖中的術語“第一”、“第二”等是用于區(qū)別類似的對象，而不必用于描述特定的順序或先后次序。

在本實施例中提供了一種告警的處理方法，圖3是根據本發(fā)明實施例的告警的處理方法的流程圖，如圖3所示，該流程包括如下步驟：

步驟S302：基站統(tǒng)計預定時間段內已產生告警中頻閃告警的信息，其中，頻閃告警為反復產生的告警，頻閃告警的信息包括：頻閃告警的類型、頻閃告警反復產生的平均周期、平均周期中正常平均持續(xù)時間、平均周期中告警平均持續(xù)時間；

步驟S304：基站上報頻閃告警的信息到網管；

步驟S306：在經過預定時間后頻閃告警未產生時，基站上報用于指示頻閃告警恢復的信息到網管，其中，預定時間為正常平均持續(xù)時間的整數倍。

在本實施例的步驟S302至步驟S306中，采用基站統(tǒng)計預定時間段內已產生告警中反復產生的頻閃告警的信息，而該信息包括：頻閃告警的類型、頻閃告警反復產生的平均周期、平均周期中正常平均持續(xù)時間、平均周期中告警平均持續(xù)時間；在統(tǒng)計完之后上報頻閃告警的信息到網管，通過該信息網管就能適時的對告警進行下單；而在經過指定時間段后頻閃告警未產生時，基站上報用于指示頻閃告警恢復的信息到網管，其中，該指定時間段為正常平均持續(xù)時間的整數倍，可見，網管上能獲取到頻閃告警以及該頻閃告警的信息，以便進行故障的排除，從而解決了相關技術中難以區(qū)分告警的抖動規(guī)律的問題，提高了處理告警的效率。

需要說明的是，本實施例中涉及到的頻閃告警為周期性產生的告警，但是對于同一頻閃告警可能在不同時間段的周期是不一致的，因此，在本實施例中涉及到的是預定時間段內產生頻閃告警的平均周期，而該平均周期中正常平均持續(xù)時間是指在一個周期中沒有告警產生的時間段，如該正常平均持續(xù)時間為600s，而平均周期中告警平均持續(xù)時間是指一次告警持續(xù)的時間為10s。

此外，本實施例中涉及到的該指定時間段為正常平均持續(xù)時間的整數倍中，整數倍可選為2或3倍，此外由于本實施例中涉及到的告警包括：快閃告警和慢閃告警，而快閃告警是指兩次告警之間的時間很短，如兩次告警的時間為5個小時，慢閃告警是指兩次告警之間的時間很長，如兩次告警之間的時間為5s。因此，該也可以根據不同類型告警的進行相應的指定時間段取值，但該指定時間段不能等于正常平均持續(xù)時間。

在本實施實例的一個可選實施方式中，在統(tǒng)計該預定時間段內已產生告警中頻閃告警的信息之前，本本實施例的方法還可以包括：預先配置頻閃告警平均周期的閾值范圍。也就是說，基站可以預先對頻閃告警的進行定義，即某一個告警的平均周期在某一個閾值范圍內時，這個告警就屬于頻閃告警，當然基站也可以不用事先配置頻閃告警的定義；基站可以通過已產生的告警進行學習，統(tǒng)計該閾值范圍內的頻閃告警的信息。

而在本實施例的另一個可選實施方式中，本實施例的方法還可以包括：在統(tǒng)計預定時間段內已產生告警中頻閃告警的信息之后，上報不在閾值范圍內的非頻閃告警，或被設置為實時上報的頻閃告警。也就是說，對于本實施例中的告警，并不對所有的告警信息進行統(tǒng)計，只統(tǒng)計是頻閃告警且沒有被設置為實時上報，不是頻閃告警或需要實時上報的頻閃告警則是直接上報的。

而對于本實施例中的進行統(tǒng)計的頻閃告警，也是可以實時上報的，需要通過如下步驟來實現：

步驟S11：基站接收實時上報頻閃告警的指令；

步驟S12：基站依據指令不對頻閃告警的信息進行統(tǒng)計，直接實時上報頻閃告警。

可見，通過上述步驟S11和步驟S12，在接收到該指令之后，不再對頻閃告警的信息進行統(tǒng)計，而是直接上報該頻閃告警。

通過以上的實施方式的描述，本領域的技術人員可以清楚地了解到根據上述實施例的方法可借助軟件加必需的通用硬件平臺的方式來實現，當然也可以通過硬件，但很多情況下前者是更佳的實施方式?；谶@樣的理解，本發(fā)明的技術方案本質上或者說對現有技術做出貢獻的部分可以以軟件產品的形式體現出來，該計算機軟件產品存儲在一個存儲介質(如ROM/RAM、磁碟、光盤)中，包括若干指令用以使得一臺終端設備(可以是手機，計算機，服務器，或者網絡設備等)執(zhí)行本發(fā)明各個實施例的方法。

在本實施例中還提供了一種告警的處理裝置，該裝置用于實現上述實施例及優(yōu)選實施方式，已經進行過說明的不再贅述。如以下所使用的，術語“模塊”可以實現預定功能的軟件和/或硬件的組合。盡管以下實施例所描述的裝置較佳地以軟件來實現，但是硬件，或者軟件和硬件的組合的實現也是可能并被構想的。

圖4是根據本發(fā)明實施例的告警的處理裝置的結構框圖，如圖4所示，該裝置包括：統(tǒng)計模塊42，用于統(tǒng)計預定時間段內已產生告警中頻閃告警的信息，其中，頻閃告警為周期性產生的告警，頻閃告警的信息包括：頻閃告警的類型、產生頻閃告警的平均周期、平均周期中正常平均持續(xù)時間、平均周期中告警平均持續(xù)時間；第一上報模塊44，與統(tǒng)計模塊42耦合連接，用于上報頻閃告警的信息；第二上報模塊46，與統(tǒng)計模塊42耦合連接，用于在經過指定時間段后頻閃告警未產生時，上報用于指示頻閃告警恢復的信息，其中，指定時間段為正常平均持續(xù)時間的整數倍。

圖5是根據本發(fā)明實施例的告警的處理裝置的可選結構框圖一，如圖5所示，在統(tǒng)計預定時間段內已產生告警中頻閃告警的信息之前，該裝置還包括：配置模塊52，與統(tǒng)計模塊42耦合連接，用于預先配置頻閃告警平均周期的閾值范圍。

圖6是根據本發(fā)明實施例的告警的處理裝置的可選結構框圖二，如圖6所示，在統(tǒng)計預定時間段內已產生告警中頻閃告警的信息之后，該裝置還包括：第三上報模塊62，與統(tǒng)計模塊42耦合連接，用于上報不在閾值范圍內的非頻閃告警，或被設置為實時上報的頻閃告警。

圖7是根據本發(fā)明實施例的告警的處理裝置的可選結構框圖三，如圖7所示，在上報用于指示頻閃告警恢復的信息之后，裝置還包括：接收模塊72，與第二上報模塊46耦合連接，用于接收實時上報頻閃告警的指令；第四上報模塊74，與接收模塊72耦合 連接，用于依據指令不對頻閃告警的信息進行統(tǒng)計，實時上報頻閃告警。

可選地，該頻閃告警包括：快閃告警和慢閃告警。

下面結合本發(fā)明的可選實施例對本發(fā)明進行舉例說明；

本可選實施例提供了一種基站頻閃告警的上報方法，該方法適用于所有告警，適用于所有頻閃情況(快閃：兩次告警之間的時間很短，慢閃：兩次告警之間的時間很長)，而且還讓用戶通過網管就對那些告警是抖動告警(對應上述實施例中的頻閃告警)及其抖動的周期(平均正常持續(xù)時間T_normal、平均告警持續(xù)時間T_alarm)一目了然，極大地方便派單及排障。本可選實施例方法的步驟包括：

步驟S402：基站對上報給網管的告警進行統(tǒng)計，找出頻閃告警

其中，頻閃告警包括：快閃告警和慢閃告警，快閃告警每幾秒鐘發(fā)生一次，慢閃告警一天甚至幾天發(fā)生一次。

步驟S404：對頻閃告警，統(tǒng)計平均告警持續(xù)時間、平均正常持續(xù)時間，上報給網管時，告警名稱仍用原告警名稱，但上報的告警詳細信息中，在正常上報的詳細信息的基礎上增加三個字段：頻閃、平均正常持續(xù)時間T_normal、平均告警持續(xù)時間T_alarm，例如，原來上報的告警名稱是光口告警，現在上報的仍然是光口告警，原來上報的詳細信息是光口1，現在的詳細信息則是光口1、頻閃、平均正常持續(xù)時間＝600s、平均告警持續(xù)時間＝10s。上報頻閃告警后，其后發(fā)生的同一告警點的告警、恢復，只參與統(tǒng)計，不上報網管，當連續(xù)n*T_normal(n在2和3之間)時間內無告警時，上報告警恢復到網管。

步驟S406：繼續(xù)監(jiān)控，重新開始統(tǒng)計，回到步驟S402。

步驟S408：網管可以隨時發(fā)送命令給基站，讓基站不要統(tǒng)計上報，而是實時上報?；窘拥皆撁詈?，立即實時上報告警、恢復(維護人員上站排障時，需要看到實時告警數據)。

采用本可選實施例的方法，對所有告警有效，網管上不但能看到穩(wěn)定的告警，便于派單，而且能明確看到哪一個告警是抖動告警以及平均正常持續(xù)時間T_normal、平均告警持續(xù)時間T_alarm，便于排障。

下面結合附圖對可選實施例進行詳細說明；

圖8是根據本發(fā)明可選實施例的基站頻閃告警的上報方法流程圖，如圖8所示，該流程的步驟包括：

基站啟動后，首先設置一個軟件過濾器，讀取基站本地的有關告警頻閃上報的配置數據，或者向網管請求有關告警頻閃上報的配置數據。這些配置數據包括：是否支持頻閃統(tǒng)計上報、告警的頻閃門限(某告警多長時間多少次為頻閃)，如果沒有讀到或某些 告警不在配置名單中，則采納缺省支持模式及缺省門限。

上報給網管的告警需要經過該軟件過濾器，過濾器記錄告警的發(fā)生次數、計算平均正常持續(xù)時間T_normal、平均告警持續(xù)時間T_alarm，判斷告警是否頻閃以及頻閃周期。

對于正常告警以及尚未判斷為頻閃的告警，或者網管要求實時上報告警，軟件過濾器正常上報告警、恢復。

對于判斷為頻閃的告警且網管沒要求實時上報，軟件過濾器在上報告警時，上報帶有頻閃詳細信息的告警，即告警名稱仍用原告警名稱，但告警詳細信息在正常上報的告警詳細信息的基礎上，增加三個字段：頻閃、平均正常持續(xù)時間T_normal、平均告警持續(xù)時間T_alarm。上報頻閃告警后，其后發(fā)生的同一告警點的告警、恢復，只參與統(tǒng)計，不上報網管，當連續(xù)n*T_normal時間內無告警時時間內無告警時(對于快閃告警，n＝3*T_normal，對于慢閃告警，n＝2*T_normal)，上報告警恢復到網管。之后當告警又發(fā)生時，重新開始統(tǒng)計，重復上面的過程。

可選地，本實施例中的具體示例可以參考上述實施例及可選實施方式中所描述的示例，本實施例在此不再贅述。

顯然，本領域的技術人員應該明白，上述的本發(fā)明的各模塊或各步驟可以用通用的計算裝置來實現，它們可以集中在單個的計算裝置上，或者分布在多個計算裝置所組成的網絡上，可選地，它們可以用計算裝置可執(zhí)行的程序代碼來實現，從而，可以將它們存儲在存儲裝置中由計算裝置來執(zhí)行，并且在某些情況下，可以以不同于此處的順序執(zhí)行所示出或描述的步驟，或者將它們分別制作成各個集成電路模塊，或者將它們中的多個模塊或步驟制作成單個集成電路模塊來實現。這樣，本發(fā)明不限制于任何特定的硬件和軟件結合。

以上所述僅為本發(fā)明的優(yōu)選實施例而已，并不用于限制本發(fā)明，對于本領域的技術人員來說，本發(fā)明可以有各種更改和變化。凡在本發(fā)明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發(fā)明的保護范圍之內。