專利名稱：通信網(wǎng)節(jié)點故障監(jiān)測方法
技術(shù)領(lǐng)域：
本發(fā)明涉及移動通信系統(tǒng)中的故障監(jiān)測方法，尤其是用于CDMA 1XEV-DO網(wǎng)絡(luò)中接入網(wǎng)認(rèn)證、授權(quán)和計費AN-AAA服務(wù)器及所述服務(wù)器與接入網(wǎng)間A12鏈路所構(gòu)成的接入網(wǎng)認(rèn)證、授權(quán)和計費系統(tǒng)的故障監(jiān)測方法。
背景技術(shù)：
盡管CDMA 1X可提供153.6Kbps的數(shù)據(jù)傳輸鏈路，但仍不能完全滿足人們高速訪問互聯(lián)網(wǎng)的要求。因此，業(yè)界開發(fā)出了CDMA 1X EV-DO的解決方案。改進型單獨傳送數(shù)據(jù)的碼分多址技術(shù)(CDMA 1X EV-DO，CDMA EvolutionDate Only)是目前較為成熟、下載速率較大并已有商用經(jīng)驗的移動數(shù)據(jù)通信技術(shù)，它與CDMA 1x相比有兩大優(yōu)點峰值速率高；容量大，可支持的用戶多，上網(wǎng)速率可達2.4Mbps。
在IP網(wǎng)絡(luò)中，數(shù)據(jù)分組的選路基于節(jié)點的IP地址，在蜂窩網(wǎng)和個人通信網(wǎng)中，呼叫的選路基于國際移動用戶識別符或移動識別號碼(IMSI/MIN)，在CDMA 1X EV-DO網(wǎng)絡(luò)中，選路不需要IMSI/MIN，所以1X EV-DO接入終端不需要提前分配IMSI/MIN。無線分組(R-P，Radio-Packet)會話在無線網(wǎng)絡(luò)控制器(RNC，Radio Network Control)和分組數(shù)據(jù)業(yè)務(wù)節(jié)點(PDSN，PacketData Serving Node)之間的切換需要另外的解決方案。為了能在連接于同一個PDSN的不同RNC/BSC之間傳送會話，移動終端的IMSI應(yīng)該始終保持不變。
由于移動終端沒有IMSI，當(dāng)RNC在移動終端和PDSN之間開始一個會話時，就給移動終端分配一個IMSI。在CDMA 1X EV-DO的標(biāo)準(zhǔn)中引入了一個新的接口A12，它是RNC和接入網(wǎng)認(rèn)證、授權(quán)和計費(AN-AAA，AccessNet-Authentication Authorization Accounting)服務(wù)器之間的接口。圖1為CDMA 1X EV-DO的網(wǎng)絡(luò)結(jié)構(gòu)圖。AN-AAA有兩個功能完成對移動終端的鑒權(quán)；在它的鑒權(quán)接受消息中向RNC返送一個IMSI值，這個IMSI用于RNC與PDSN建立R-P會話。
若在CDMA 1X EV-DO網(wǎng)絡(luò)中沒有AN-AAA服務(wù)器，則CDMA 1X EV-DO的RNC和CDMA 1X的BSC之間無法完成R-P會話切換，移動終端只能依靠移動IP來保持它的IP地址在穿過網(wǎng)絡(luò)邊緣時不變。如果網(wǎng)絡(luò)沒有移動IP功能，在移動終端通過網(wǎng)絡(luò)邊緣時，必須分配新的IP地址，部署AN-AAA服務(wù)器有利于快速切換和改善移動終端通過網(wǎng)絡(luò)邊緣時的性能。
現(xiàn)有技術(shù)中通過用標(biāo)準(zhǔn)命令ping通AN-AAA服務(wù)器的IP地址實現(xiàn)對A12鏈路及AN-AAA服務(wù)器硬件故障的監(jiān)測。所謂ping命令是讓目前所在的主機向目標(biāo)主機發(fā)送一個“數(shù)據(jù)包”，目標(biāo)主機在接收到這個“數(shù)據(jù)包”時會立即自動反饋一個數(shù)據(jù)包，以此來表示主機間通信的暢通。若從AN無法ping通AN-AAA服務(wù)器的IP地址，則該服務(wù)器或其與接入網(wǎng)之間的通信鏈路A12存在故障。在現(xiàn)有技術(shù)的基礎(chǔ)上，周期性的應(yīng)用ping命令向目標(biāo)主機發(fā)送“數(shù)據(jù)包”，可以實現(xiàn)對AN-AAA服務(wù)器及其與接入網(wǎng)之間的通信鏈路A12所構(gòu)成的系統(tǒng)故障的實時監(jiān)測，但現(xiàn)有技術(shù)只能對該系統(tǒng)的硬件故障實現(xiàn)實時監(jiān)測，而無法實現(xiàn)對應(yīng)用層軟件的實時監(jiān)測，對于軟件的故障仍然需要通過人為的檢測。

發(fā)明內(nèi)容
本發(fā)明所要解決的技術(shù)問題是提供一種故障監(jiān)測方法，該方法可以實現(xiàn)對接入網(wǎng)認(rèn)證、授權(quán)和計費AN-AAA服務(wù)器及其與接入網(wǎng)間通信鏈路A12所構(gòu)成的接入網(wǎng)認(rèn)證、授權(quán)和計費系統(tǒng)硬件故障及軟件故障的實時監(jiān)測。
為解決上述問題，本發(fā)明提供了一種通信網(wǎng)節(jié)點故障監(jiān)測方法，用于實現(xiàn)對接入網(wǎng)認(rèn)證、授權(quán)和計費AN-AAA服務(wù)器及其與接入網(wǎng)間通信鏈路A12所構(gòu)成的系統(tǒng)故障的監(jiān)測，具體步驟為1)源側(cè)接入網(wǎng)向所述服務(wù)器發(fā)送接入請求消息；2)判斷在預(yù)置的等待時長內(nèi)是否收到所述服務(wù)器回應(yīng)消息，若沒有收到，進行硬件故障告警處理；若收到則進行步驟3)；
3)判斷所述回應(yīng)消息是否為接入允許消息，若不是則進行軟件故障告警處理。
在步驟2)中，所述硬件故障告警處理的過程進一步包括判斷是否需要發(fā)送硬件故障告警，以及當(dāng)需要發(fā)送硬件故障告警時發(fā)送硬件故障告警的步驟。
若判斷不進行硬件故障告警時，可以將預(yù)置的硬件故障計數(shù)器累加一個單位值。在步驟2)中進行硬件故障告警或步驟3)中判斷回應(yīng)消息為接入允許消息后，將所述計數(shù)器值置零。根據(jù)本方法中對計數(shù)器的設(shè)置，步驟2)中所包括的判斷是否需要發(fā)送硬件故障告警的步驟具體為判斷所述硬件故障計數(shù)器的值是否大于預(yù)置的最大硬件故障次數(shù)，若大于預(yù)置的最大硬件故障次數(shù)則需要進行硬件故障告警，否則不需要進行硬件故障告警。
在步驟3)中，所述軟件故障告警處理的過程進一步包括判斷是否需要發(fā)送軟件故障告警，以及當(dāng)需要發(fā)送軟件故障告警時發(fā)送軟件故障告警的步驟。
若判斷不進行軟件故障告警，可以將預(yù)置的軟件故障計數(shù)器累加一個單位值，在步驟3)中判斷回應(yīng)消息為接入允許消息后或進行軟件故障告警，將所述計數(shù)器值置零。根據(jù)本方法對計數(shù)器的設(shè)置，步驟3)中所包括的判斷是否需要發(fā)送軟件故障告警的步驟具體為判斷所述軟件故障計數(shù)器的值是否大于預(yù)置的最大軟件故障次數(shù)，若大于預(yù)置的最大軟件故障次數(shù)則需要進行軟件故障告警，否則不需要進行軟件故障告警。
步驟1)之前，在接入網(wǎng)認(rèn)證、授權(quán)和計費服務(wù)器中預(yù)置專用于監(jiān)測所述服務(wù)器和通信鏈路A12故障的虛擬用戶，該虛擬用戶資源不提供給實際的用戶使用。
本發(fā)明的步驟1)具體為源側(cè)接入網(wǎng)向主服務(wù)器發(fā)送接入請求消息；在步驟3)中判斷為接入允許消息后，則源側(cè)接入網(wǎng)向備服務(wù)器發(fā)送接入請求消息，并返回步驟2)，以繼續(xù)監(jiān)測備用服務(wù)器是否出現(xiàn)故障。
本方法中所稱的接入請求消息、接入允許消息為通信鏈路A12的標(biāo)準(zhǔn)接口消息。
與現(xiàn)有技術(shù)相比，本發(fā)明具有以下優(yōu)點該方法的利用了系統(tǒng)中已有的A12標(biāo)準(zhǔn)接口，通過對鏈路接口標(biāo)準(zhǔn)命令的判斷，實現(xiàn)對接入網(wǎng)認(rèn)證、授權(quán)和計費AN-AAA服務(wù)器及其通信鏈路A12所構(gòu)成系統(tǒng)的硬件故障及軟件故障的實時監(jiān)測，進而可以將初步的故障定位及時告知維護人員，從而可以幫助維護人員及時排除故障，有利于縮短系統(tǒng)故障的修復(fù)時間，將因AN-AAA服務(wù)器及其鏈路A12故障所帶來的影響降低。


圖1為CDMA 1X EV-DO的網(wǎng)絡(luò)結(jié)構(gòu)圖；圖2為用于故障實時監(jiān)測的消息流程圖；圖3為本發(fā)明實現(xiàn)故障實時監(jiān)測的一較佳實施例流程圖。
具體實施例方式
本發(fā)明所要解決的技術(shù)問題是提供一種對接入網(wǎng)認(rèn)證、授權(quán)和計費AN-AAA服務(wù)器及其通信鏈路A12的硬件及軟件故障的實時監(jiān)測的方法，該方法的核心在于利用了系統(tǒng)中已有的A12標(biāo)準(zhǔn)接口，通過對鏈路接口標(biāo)準(zhǔn)命令的判斷，實現(xiàn)對故障的實時監(jiān)測。
為了使本技術(shù)領(lǐng)域的人員更好地理解本發(fā)明方案，下面結(jié)合附圖和實施方式對本發(fā)明作進一步的詳細(xì)說明。
本方法一較佳實施例的實現(xiàn)方式為在AN-AAA服務(wù)器上設(shè)立一個保留的虛擬用戶，該用戶不分配給實際的用戶使用，只用于故障檢測；在AN中增加如下功能設(shè)置一個監(jiān)測定時器及監(jiān)測時長，設(shè)置一用于計算等待AN-AAA服務(wù)器回應(yīng)消息時長的等待定時器及該定時器的等待時長，所述的監(jiān)測定時器的監(jiān)測時長大于所述的等待時長，并且監(jiān)測定時器屬于周期定時器；分別預(yù)置因軟件及硬件故障導(dǎo)致消息重發(fā)的最大重發(fā)次數(shù)。監(jiān)測定時器定時觸發(fā)AN向AN-AAA服務(wù)器發(fā)送該虛擬用戶的A12Access-Request，用以監(jiān)測AN-AAA服務(wù)器的可用性，其消息流程圖如圖2所示。
參照圖3所示的本發(fā)明一較佳實施例的流程，本方法包括以下步驟步驟11啟動監(jiān)測定時器，置硬件故障重發(fā)次數(shù)及軟件故障重發(fā)次數(shù)為0；步驟12當(dāng)監(jiān)測定時器超過監(jiān)測時長，接入網(wǎng)AN以AN-AAA服務(wù)器上預(yù)置的虛擬用戶的名義向AN-AAA服務(wù)器發(fā)送A12的接入請求(Access-Request)消息，啟動等待定時器，并等待AN-AAA服務(wù)器的回應(yīng)消息；步驟13判斷在預(yù)置的等待定時器的等待時長內(nèi)是否收到了AN-AAA服務(wù)器的回應(yīng)消息，如果收到了所述服務(wù)器的回應(yīng)消息，則進行步驟19停止等待定時器的計時，并且進行步驟20；若在預(yù)置的等待時長內(nèi)沒有收到所述服務(wù)器的回應(yīng)消息，則進行步驟14；步驟14判斷硬件故障重發(fā)次數(shù)是否大于預(yù)置的硬件故障最大重發(fā)次數(shù)，若硬件故障重發(fā)次數(shù)大于預(yù)置的硬件故障最大重發(fā)次數(shù)，則證明AN-AAA服務(wù)器及其鏈路A12存在硬件故障，并進行步驟15；若硬件故障重發(fā)次數(shù)小于或等于預(yù)置的硬件故障最大重發(fā)次數(shù)，則進行步驟16；所述硬件故障重發(fā)次數(shù)是用于統(tǒng)計在發(fā)送一次硬件故障告警或一次監(jiān)測證明服務(wù)器及其鏈路A12工作正常之前由于未能在預(yù)置的等待時長內(nèi)收到服務(wù)器回應(yīng)消息而促使重新發(fā)送接入請求消息的次數(shù)，即為在等待時長內(nèi)未收到回應(yīng)消息而且未發(fā)送硬件故障告警的次數(shù)；步驟15AN發(fā)送AN-AAA服務(wù)器及其鏈路A12的硬件故障告警，即向網(wǎng)管中心發(fā)送A12硬件故障告警報文，后續(xù)由網(wǎng)管中心進行故障告警及處理，并進行步驟26；步驟16將硬件故障重發(fā)次數(shù)加1，不發(fā)送硬件故障告警，進行步驟17；步驟17重新以保留的虛擬用戶的名義向AN-AAA服務(wù)器發(fā)送A12的接入請求(Access-Request)消息，重新啟動等待定時器用于計算等待時長，并進行步驟18；步驟18重新啟動監(jiān)測定時器，并且返回步驟13；步驟20判斷收到的所述服務(wù)器的回應(yīng)消息是否為A12的接入允許(Access-Accept)消息，如果是A12的接入允許消息，則說明當(dāng)前AN-AAA服務(wù)器及其鏈路A12工作正常，進行步驟26；如果不是A12的接入允許消息，則進行步驟21，由于在AN-AAA服務(wù)器上已經(jīng)預(yù)置了虛擬用戶，該用戶的接入用戶名和密碼是對應(yīng)預(yù)先設(shè)置并對AN是已知的，因而不會出現(xiàn)由于錯誤的用戶名或密碼而使得AN-AAA服務(wù)器不能發(fā)送接入允許消息的情況，因此，所述服務(wù)器會發(fā)送A12的接入拒絕(Access-Reject)消息代替A12的接入允許(Access-Accept)消息，由此消息可判斷為當(dāng)前服務(wù)器存在軟件故障；步驟21判斷軟件故障重發(fā)次數(shù)是否大于預(yù)置的軟件故障最大重發(fā)次數(shù)，若軟件故障重發(fā)次數(shù)大于預(yù)置的軟件故障最大重發(fā)次數(shù)，則證明AN-AAA服務(wù)器存在軟件故障，并進行步驟22；若軟件故障重發(fā)次數(shù)小于或等于預(yù)置的軟件故障最大重發(fā)次數(shù)，則進行步驟23；所述軟件故障重發(fā)次數(shù)是用于統(tǒng)計在發(fā)送一次軟件故障告警或一次監(jiān)測證明服務(wù)器及其鏈路A12工作正常之前由于所收到的服務(wù)器的回應(yīng)消息是以接入拒絕(Access-Reject)消息替代接入允許(Access-Accept)消息而促使重新發(fā)送接入請求消息的次數(shù)，即為回應(yīng)消息不為接入允許消息而且未發(fā)送軟件故障告警的次數(shù)；步驟22發(fā)送軟件故障告警，即向網(wǎng)管中心發(fā)送A12軟件故障告警報文，后續(xù)由網(wǎng)管中心進行故障告警及處理，并進行步驟26；步驟23將軟件故障重發(fā)次數(shù)加1，硬件故障重發(fā)次數(shù)置零，不發(fā)送軟件故障告警，進行步驟24；步驟24重新以保留的虛擬用戶的名義向AN-AAA服務(wù)器發(fā)送A12的接入請求(Access-Request)消息，重新啟動等待定時器用于計算等待時長，并進行步驟25；步驟25重新啟動監(jiān)測定時器，并且返回步驟13；步驟26將軟件故障重發(fā)次數(shù)和硬件故障重發(fā)次數(shù)清零，并返回步驟12。
以上為本發(fā)明的一較佳實施例，同樣本方法的其他實現(xiàn)形式同樣可以達到本發(fā)明的目的。
替代圖3所示實施例的一方法為在發(fā)現(xiàn)硬件或軟件故障的時候不再對是否需要發(fā)送硬件故障告警或軟件故障告警進行判斷。其實施例具體為設(shè)置系統(tǒng)時，在AN-AAA服務(wù)器上設(shè)立一個保留的虛擬用戶，該用戶不分配給實際的用戶使用，只用于故障檢測；在AN中增加如下功能設(shè)置一個監(jiān)測定時器及監(jiān)測時長，設(shè)置一用于計算等待AN-AAA服務(wù)器回應(yīng)消息時長的等待定時器及該定時器的等待時長，所述的監(jiān)測定時器的監(jiān)測時長大于所述的等待時長，并且監(jiān)測定時器屬于周期定時器。
啟動監(jiān)測定時器；當(dāng)監(jiān)測定時器超過監(jiān)測時長，接入網(wǎng)AN以AN-AAA服務(wù)器上預(yù)置的虛擬用戶的名義向AN-AAA服務(wù)器發(fā)送A12的接入請求(Access-Request)消息，監(jiān)測定時器立刻重新啟動開始計時；啟動等待定時器，等待AN-AAA服務(wù)器的回應(yīng)消息；判斷在預(yù)置的等待定時器的等待時長內(nèi)是否收到了AN-AAA服務(wù)器的回應(yīng)消息，若在預(yù)置的等待時長內(nèi)沒有收到所述服務(wù)器的回應(yīng)消息，則認(rèn)為出現(xiàn)了硬件故障，立刻進行硬件故障告警，并等待監(jiān)測定時器超過監(jiān)測時長后重新向AN-AAA服務(wù)器發(fā)送A12的Access-Request；如果收到了所述服務(wù)器的回應(yīng)消息，則停止等待定時器。
判斷收到的所述服務(wù)器的回應(yīng)消息是否為A12的接入允許(Access-Accept)消息，如果是A12的接入允許消息，則說明當(dāng)前AN-AAA服務(wù)器及其鏈路A12工作正常，則等待監(jiān)測定時器超過監(jiān)測時長后重新向AN-AAA服務(wù)器發(fā)送A12的Access-Request；如果所述的回應(yīng)消息不是A12的接入允許消息，則認(rèn)為出現(xiàn)了軟件故障，立刻進行軟件故障告警，并等待監(jiān)測定時器超過監(jiān)測時長后重新向AN-AAA服務(wù)器發(fā)送A12的Access-Request。由于在AN-AAA服務(wù)器上已經(jīng)預(yù)置了虛擬用戶，該用戶的接入用戶名和密碼是對應(yīng)預(yù)先設(shè)置并對AN是已知的，因而不會出現(xiàn)由于錯誤的用戶名或密碼而使得AN-AAA服務(wù)器不能發(fā)送接入允許消息的情況，因此，所述服務(wù)器會發(fā)送A12的接入拒絕(Access-Reject)消息代替A12的接入允許(Access-Accept)消息，由此消息可判斷為當(dāng)前服務(wù)器存在軟件故障。
另外，圖3所示實施例中，在是否發(fā)送硬件故障告警或軟件故障告警的判斷中，通過判斷故障重發(fā)次數(shù)是否大于預(yù)置的故障最大重發(fā)次數(shù)決定是否進行故障告警。對于此步驟目的的實現(xiàn)可以通過多種方式，例如，在圖3所示的實施例中，當(dāng)出現(xiàn)硬件故障時立刻重新向AN-AAA服務(wù)器發(fā)送Access-Request，因而可以預(yù)置硬件故障最大重發(fā)時長，當(dāng)由于硬件故障而連續(xù)重發(fā)Access-Request的時長大于預(yù)置的硬件故障最大時長時，即發(fā)送硬件故障告警；以同樣的方法可以實現(xiàn)對是否發(fā)送軟件故障告警的控制。
在第一實施例中，在發(fā)送硬件故障告警后，將硬件故障重發(fā)次數(shù)置零；在發(fā)送軟件故障告警后，將軟件故障重發(fā)次數(shù)置零；將軟件故障重發(fā)次數(shù)加1的同時將硬件故障重發(fā)次數(shù)置零；以及判斷收到的所述服務(wù)器的回應(yīng)消息為A12的接入允許(Access-Accept)消息后將硬件故障重發(fā)次數(shù)和軟件故障重發(fā)次數(shù)置零。以上置零的步驟可以由其他方式代替而實現(xiàn)同樣的效果，如在上述的各個過程中，取消置零的步驟，而將預(yù)置的硬件故障最大重發(fā)次數(shù)及軟件故障最大重發(fā)次數(shù)在已有基礎(chǔ)上進行累加得到新的最大重發(fā)次數(shù)。即在發(fā)送硬件故障告警后，將硬件故障重發(fā)次數(shù)與已有的硬件故障最大重發(fā)次數(shù)相加，得到新的硬件故障最大重發(fā)次數(shù)；在發(fā)送軟件故障告警后，將軟件故障重發(fā)次數(shù)與已有的軟件故障最大重發(fā)次數(shù)相加，得到新的軟件故障最大重發(fā)次數(shù)；將軟件故障重發(fā)次數(shù)加1的同時將硬件故障重發(fā)次數(shù)與已有的硬件故障最大重發(fā)次數(shù)相加，得到新的硬件故障最大重發(fā)次數(shù)；判斷收到的所述服務(wù)器的回應(yīng)消息為A12的接入允許(Access-Accept)消息后分別將硬件故障重發(fā)次數(shù)與已有的硬件故障最大重發(fā)次數(shù)相加得到新的硬件故障最大重發(fā)次數(shù)，并且將軟件故障重發(fā)次數(shù)與已有的軟件故障最大重發(fā)次數(shù)相加，得到新的軟件故障最大重發(fā)次數(shù)。
如圖4所示，若網(wǎng)絡(luò)中存在主用服務(wù)器和備用服務(wù)器，則AN先向主用服務(wù)器發(fā)送接入請求(Access-Request)消息，對主服務(wù)器進行故障檢測，當(dāng)檢測結(jié)果表明主服務(wù)器不存在故障時，即判斷收到的所述服務(wù)器的回應(yīng)消息為A12的接入允許(Access-Accept)消息，并將軟件故障重發(fā)次數(shù)和硬件故障重發(fā)次數(shù)清零時，AN向備用服務(wù)器發(fā)送接入請求(Access-Request)消息，并且按照監(jiān)測主服務(wù)器的方法對備用服務(wù)器的故障進行檢測。
以上對本發(fā)明所提供的接入網(wǎng)認(rèn)證、授權(quán)和計費系統(tǒng)的故障監(jiān)測方法進行了詳細(xì)介紹，本文中應(yīng)用了具體個例對本發(fā)明的原理及實施方式進行了闡述，以上實施例的說明只是用于幫助理解本發(fā)明的方法及其核心思想；同時，對于本領(lǐng)域的一般技術(shù)人員，依據(jù)本發(fā)明的思想，在具體實施方式
及應(yīng)用范圍上均會有改變之處，因此，本說明書內(nèi)容不應(yīng)理解為對本發(fā)明的限制。
權(quán)利要求
1.一種通信網(wǎng)節(jié)點故障監(jiān)測方法，用于實現(xiàn)對接入網(wǎng)認(rèn)證、授權(quán)和計費AN-AAA服務(wù)器及其與接入網(wǎng)間通信鏈路A12所構(gòu)成的系統(tǒng)故障的監(jiān)測，其特征在于1)源側(cè)接入網(wǎng)向所述服務(wù)器發(fā)送接入請求消息；2)判斷在預(yù)置的等待時長內(nèi)是否收到所述服務(wù)器回應(yīng)消息，若沒有收到，進行硬件故障告警處理；若收到則進行步驟3)；3)判斷所述回應(yīng)消息是否為接入允許消息，若不是則進行軟件故障告警處理。
2.如權(quán)利要求1所述的通信網(wǎng)節(jié)點故障監(jiān)測方法，其特征在于，步驟2)所述硬件故障告警處理的過程進一步包括判斷是否需要發(fā)送硬件故障告警，以及當(dāng)需要發(fā)送硬件故障告警時發(fā)送硬件故障告警的步驟。
3.如權(quán)利要求2所述的通信網(wǎng)節(jié)點故障監(jiān)測方法，其特征在于步驟2)中判斷不進行硬件故障告警時，將預(yù)置的硬件故障計數(shù)器累加一個單位值；步驟2)中進行硬件故障告警或步驟3)中判斷回應(yīng)消息為接入允許消息后，將所述計數(shù)器值置零。
4.如權(quán)利要求3所述的通信網(wǎng)節(jié)點故障監(jiān)測方法，其特征在于，所述判斷是否需要發(fā)送硬件故障告警的步驟具體為判斷所述硬件故障計數(shù)器的值是否大于預(yù)置的最大硬件故障次數(shù)，若大于預(yù)置的最大硬件故障次數(shù)則需要進行硬件故障告警，否則不需要進行硬件故障告警。
5.如權(quán)利要求1至4其中之一所述的通信網(wǎng)節(jié)點故障監(jiān)測方法，其特征在于，步驟3)所述軟件故障告警處理的過程進一步包括判斷是否需要發(fā)送軟件故障告警，以及當(dāng)需要發(fā)送軟件故障告警時發(fā)送軟件故障告警的步驟。
6.如權(quán)利要求5所述的通信網(wǎng)節(jié)點故障監(jiān)測方法，其特征在于步驟3)中判斷不進行軟件故障告警時，將預(yù)置的軟件故障計數(shù)器累加一個單位值；步驟3)中判斷回應(yīng)消息為接入允許消息或進行軟件故障告警后，將所述計數(shù)器值置零。
7.如權(quán)利要求6所述的通信網(wǎng)節(jié)點故障監(jiān)測方法，其特征在于，所述判斷是否需要發(fā)送軟件故障告警的步驟具體為判斷所述軟件故障計數(shù)器的值是否大于預(yù)置的最大軟件故障次數(shù)，若大于預(yù)置的最大軟件故障次數(shù)則需要進行軟件故障告警，否則不需要進行軟件故障告警。
8.如權(quán)利要求1所述的通信網(wǎng)節(jié)點故障監(jiān)測方法，其特征在于步驟1)之前在所述服務(wù)器中預(yù)置專用于監(jiān)測所述服務(wù)器和通信鏈路A12故障的虛擬用戶。
9.如權(quán)利要求1所述的通信網(wǎng)節(jié)點故障監(jiān)測方法，其特征在于步驟1)具體為源側(cè)接入網(wǎng)向主服務(wù)器發(fā)送接入請求消息；步驟3)中若判斷為接入允許消息，則源側(cè)接入網(wǎng)向備服務(wù)器發(fā)送接入請求消息，并返回步驟2)。
10.如權(quán)利要求1或9所述的通信網(wǎng)節(jié)點故障監(jiān)測方法，所述的接入請求消息、接入允許消息為通信鏈路A12的標(biāo)準(zhǔn)接口消息。
全文摘要
本發(fā)明涉及一種通信網(wǎng)節(jié)點故障監(jiān)測方法，用于實現(xiàn)對接入網(wǎng)認(rèn)證、授權(quán)和計費AN－AAA服務(wù)器及其與接入網(wǎng)間通信鏈路A12所構(gòu)成的系統(tǒng)故障的監(jiān)測。該方法步驟包括源側(cè)接入網(wǎng)向所述服務(wù)器發(fā)送接入請求消息；判斷在預(yù)置的等待時長內(nèi)是否收到所述服務(wù)器回應(yīng)消息，若沒有收到，進行硬件故障告警處理；若收到判斷所述回應(yīng)消息是否為接入允許消息，若不是則進行軟件故障告警處理。該方法的利用了系統(tǒng)中已有的A12標(biāo)準(zhǔn)接口，通過對鏈路接口標(biāo)準(zhǔn)命令的判斷，實現(xiàn)對AN－AAA服務(wù)器及其通信鏈路A12所構(gòu)成系統(tǒng)的硬件故障及軟件故障的實時監(jiān)測，進而可以幫助維護人員及時排除故障，有利于縮短系統(tǒng)故障的修復(fù)時間，將因AN－AAA服務(wù)器及其鏈路A12故障所帶來的影響降低。
文檔編號H04L1/12GK1773943SQ20041009091
公開日2006年5月17日 申請日期2004年11月10日 優(yōu)先權(quán)日2004年11月10日
發(fā)明者徐瑩 申請人:華為技術(shù)有限公司