本發(fā)明涉及通訊的技術領域,具體地說是通訊網(wǎng)管中信令的跟蹤及識別技術。
背景技術:
在通信領域中,信令跟蹤系統(tǒng)得到廣泛使用,信令跟蹤系統(tǒng)用于跟蹤各種信令的流程,它是網(wǎng)管系統(tǒng)中日常維護非常重要的一個組成部分,為網(wǎng)管維護人員在日常維護中提供了分析問題、定位問題、解決問題的方法。
目前的信令跟蹤系統(tǒng)主要是將網(wǎng)元產(chǎn)生的信令采集并展示給用戶,用戶只能逐條查看單網(wǎng)元上報的信令,然后根據(jù)業(yè)務知識將孤立的信令串聯(lián)起來。這樣的方式明顯的增大了使用系統(tǒng)的難度(只有很有經(jīng)驗的人員才能熟練的使用),既不利于對流程的分析,也不利于問題的定位,同時在使用系統(tǒng)與其他人員交流的時候,也增加了難度。如果能夠將網(wǎng)元間的信令流程識別出來,然后在此基礎上,將異常流程提取出來(在實際的使用過程中,用戶最希望的是借助系統(tǒng),能夠快速的定位問題),將極大的提高系統(tǒng)輔助定位、分析、解決問題的能力。
專利申請201310585403.2公開了一種信令流程分析系統(tǒng)和方法,其包括:信令采集步驟、信令預處理步驟、信令流程分析步驟、狀態(tài)機編輯步驟、腳本編輯步驟、腳本解釋步驟;以及一種信令流程分析系統(tǒng),其包括:信令采集模塊、信令預處理模塊、信令流程分析模塊、狀態(tài)機編輯模塊、腳本編輯模塊、腳本解釋模塊。其中信令流程分析步驟或模塊結合lua腳本的自定義狀態(tài)機,接收、分析和計算信令,并將自定義狀態(tài)機的最終狀態(tài)作為分析結果 輸出至一應用使用。然而該方法主要是用于分析和提取信令,通過lua腳本來定義信令流程的判定規(guī)則,以直觀的圖形界面來創(chuàng)建編輯狀態(tài)機,對異常信令缺乏一個判斷規(guī)則,難以準確識別異常的信令流程。
專利申請201510427534.7公開了一種信令流程的識別方法及裝置。用于在信令流程分析過程中,提高信令流程的識別準確性。綜上所述,本發(fā)明實施例中,預先將每一個信令視為若干元素的組合,結合信令的交互規(guī)則,提取出各類典型信令流程的綜合特征,生成相應的配置文件集合,接著,基于實際獲得的信令交互數(shù)據(jù),提取出信令交互數(shù)據(jù)中包含的每一條信令的綜合特征,再基于提取出的綜合特征,采用獲得的配置文件集合在信令交互數(shù)據(jù)中進行匹配,識別出與配置文件集合匹配的目標信令流程。這樣,當目標信令流程變更時,只需調(diào)整配置文件,無需修改代碼,從而大大提高了信令流程識別的靈活性、準確性,以及加快了處理速度,并且有效降低了軟件的運維成本。該方法只是通過對信令的判斷識別調(diào)整配置文件,對于異常信令并無處理方法。
技術實現(xiàn)要素:
本發(fā)明的目的在于,提供一種信令流程模型識別方法及異常信令流程辨識方法,該方法用于信令跟蹤系統(tǒng),用來解決現(xiàn)有信令跟蹤系統(tǒng)中只能查看單條信令,不能查看信令流程的問題。
本發(fā)明的另一個目的在于提供一種信令流程模型識別方法及異常信令流程辨識方法,該方法能夠快速提取出信令流程,并識別出異常信令流程,能夠快速的定位到發(fā)生問題的網(wǎng)元以及問題產(chǎn)生的原因,提高排除問題的效率,便于日常的系統(tǒng)維護。
基于此,本發(fā)明是通過以下方式實現(xiàn)的。
一種信令流程模型的識別方法,其特征在于該方法梳理各業(yè)務操作對應的信令流程,進而抽象出信令流程模型,主要內(nèi)容包括:
抽象信令流程:包括信令流程的起始信令、結束信令、業(yè)務操作名稱、可能包含的子流程;
抽象關鍵信令:針對信令流程模型中的起始信令、結束信令進行標識定義,用于信令識別;主要包括信令對應的信令名稱、事件號、協(xié)議、上報網(wǎng)元類型、發(fā)送信令還是接受信令等信息;
抽象出信令流程后,對關鍵信令進行標識定義,然后建立信令流程模型,通過信令流程模型對信令進行識別。
所述信令流程模型,包括:
起始信令:信令流程的觸發(fā)信令,也可以說是流程的第一條信令;
中間信令:除起始、結束信令之外的,在網(wǎng)元間傳遞和轉換的信令,該部分信令的特點是某些信令會根據(jù)不同的組網(wǎng)、業(yè)務等情況,會條件的出現(xiàn);
結束信令:信令流程的最后一條信令,該條信令標識流程的完結。
所述中間信令,其可以分成兩大類:流程必定包含的信令和流程可能包含的信令。
所述方法,在關鍵信令和信令流程模型的基礎上,依據(jù)網(wǎng)元上報的信令,進行信令流程提取。所述信令流程提取是逐條遍歷信令文件中的所有信令,匹配出能和配置的信令流程模型匹配的起始信令,然后逐條遍歷出能和配置的信令流程模型匹配的結束信令,結束信令有可能有多條,需要向后遍歷出最后一條結束信令。
對于已識別的流程,記錄流程的起始信令和結束信令的索引,便于展示單元進行流程的繪制和展示。
所述方法,對于代表業(yè)務失敗的信令(都包含于中間信令中)一般通過信令事件名稱或者信令的原因碼進行標識,依據(jù)3gpp規(guī)范整理業(yè)務操作可能的失敗事件名稱以及失敗原因碼的取值列表,遍歷并解析信令文件,依據(jù)整理的失敗列表識別異常信令。在信令流程提取出來的基礎上,將包含異常信令的信令流程進行標識,便于用戶第一時間識別異常。
同時,識別沒有關聯(lián)信令的單點信令,如果信令的發(fā)送或者接收網(wǎng)元為系統(tǒng)已經(jīng)接入的網(wǎng)元,有可能對端網(wǎng)元漏報了信令,也可能網(wǎng)元發(fā)了,但是信令跟蹤系統(tǒng)沒有接收到。對于單點信令,使用虛線進行標識。
所述方法,具體包括如下步驟:
遍歷采集到的信令數(shù)據(jù)集合;
判斷提取出的集合中的一條信令是否能和某個配置的業(yè)務信令流程的起始信令相匹配,如果不能,則繼續(xù)遍歷采集到的信令數(shù)據(jù)集合;
如果信令是某個業(yè)務流程的起始信令,則找到與起始信令對應的結束信令組;
遍歷結束信令組,從若干結束信令中提取出一條失敗信令,然后從信令集合中當前信令的下一條開始索引結束信令,如果沒有索引到結束信令,則繼續(xù)遍歷結束信令,直到遍歷結束;
如果索引到了結束信令,則依據(jù)起始信令編號和結束信令編號將這一閉區(qū)間的信令全部提取出來;
流程清洗;利用之前業(yè)務流程中定義的信令(起始、結束信令以及中間信令)對流程進行清洗,將流程中不在其中的信令移除;
將清洗后的信令提取出來,并將起始、結束信令打上標記,構建信令流程;
繼續(xù)遍歷采集到的信令數(shù)據(jù)集合,直到遍歷到最后一條信令,將所有的信令流程都提取出來為止。
在流程清洗前,先對多個網(wǎng)元上報的信令進行排序,排序主要的依據(jù)是單網(wǎng)元信令的上報順序,以及信令的時間戳,由于網(wǎng)元時間的不一致以及業(yè)務的復雜性(比如正在做數(shù)據(jù)業(yè)務,之間來了電話),都會導致提取的流程中可能會夾雜不是本流程的信令,將流程中不是本流程的信令移除。
所述遍歷采集到的信令數(shù)據(jù)集合,不是從結束信令開始遍歷,而是從起始信令的下一條開始。
一種異常信令流程辨識方法,其特征在于該方法的步驟如下:
提取出的信令流程;
遍歷信令流程中包含起始、結束信令區(qū)間的信令;
通過一條信令判斷信令是否失敗,將流程標識為異常流程;
遍歷該流程中所有的信令;
流程遍歷結束后,獲取并遍歷該業(yè)務流程模型中定義的中間信令中必有部分的信令;
如果中間信令必有部分的信令中的一條在信令流程中能夠匹配到,則繼續(xù)遍歷,如果匹配不到,則判斷該條信令的發(fā)送網(wǎng)元類型在信令流程中是否只包含一個該類型被跟蹤的網(wǎng)元,如果只有一個,則能確定該網(wǎng)元缺失信令,如果有多個,則只能確定該流程中缺失該條信令,并將流程標識為異常流程;
待流程遍歷結束后,利用md5將發(fā)送和接收的信令關聯(lián)起來;
在關聯(lián)的過程中辨識是否存在不能匹配的信令,或稱單點信令,如果該信令所對應的源或者目的ip是系統(tǒng)中跟蹤網(wǎng)元的ip,則說明流程異常,標記出問題的網(wǎng)元后,將該流程標識為異常流程。
所述判斷信令是否失敗,進一步包括:如果其中一條信令的名稱直接標識信令失敗,則將流程標識為異常流程;
如果不能直接通過名稱來判斷信令是否失敗,則需要識別一下該信令是否包含原因碼,如果包含原因碼,則提取原因碼,如果不包含,則繼續(xù)遍歷流程中的信令;
對于提取出來的原因碼,判斷該原因碼是否標識該信令失敗,如果標識的是失敗,則提取信令的網(wǎng)元名,用以標識流程在該網(wǎng)元處發(fā)生失敗,并將流程標識為異常流程。
進一步,所述網(wǎng)元名提取的方法是根據(jù)信令的方向,如果是發(fā)送的,直接提取網(wǎng)元名稱,如果是接收的,則利用md5找到關聯(lián)的發(fā)送信令,再提出網(wǎng)元名稱。
所述的異常信令流程辨識方法,進一步包括有重復上述操作,將所有流程異常流程全部識別出來。
與現(xiàn)有的技術相比,本發(fā)明可以依據(jù)網(wǎng)元上報的單條信令,提取出信令流程,并識別出異常信令流程。將網(wǎng)元間的信令流程識別出來,然后在此基礎上,將異常流程提取出來,將極大的提高系統(tǒng)信令分析、輔助定位、解決問題的能力。
通過異常信令流程,能夠快速的定位到發(fā)生問題的網(wǎng)元以及問題產(chǎn)生的原因,極大地提高排除問題的效率,也為日常的系統(tǒng)維護提供了很大的便利;同時,信令流程作為信令跟蹤的基本概念,為用戶分析或者用戶間交流提供了公共的語言。
附圖說明
圖1是一個信令流程的示意圖。
圖2是本發(fā)明中提取信令流程的流程圖。
圖3是本發(fā)明中辨識異常信令流程的流程圖。
圖4是本發(fā)明第一實施例的客戶端信令流程提取與異常信令流程識別流程圖。
圖5是本發(fā)明第二實施例的客戶端查看服務器定時信令分析結果流程圖。
具體實施方式
下面結合附圖對本發(fā)明的具體實施做出詳細描述,但是應當理解的是對于本發(fā)明的詳細描述并不代表實現(xiàn)本發(fā)明的所有實現(xiàn)方式。
以附著流程為例,如圖1所示,定義一個信令流程。
圖中所示,附著流程包括有:
起始信令:
attachrequest
結束信令組:
attachreject
modifybearerresponse
因為圖1是個正常流程,而attachreject是異常信令流程的結束信令,在圖1中沒有,其是出現(xiàn)在異常信令流程中。
中間信令(必有):
createsessionrequest
createsessionresponse
initialcontextsetuprequest
等等。
中間信令(可有)
deletesessionrequest
deletesessionresponse
等等。
依據(jù)上面的信令流程模型并結合具體的業(yè)務,可以定義出若干業(yè)務信令流程。
對于抽象信令流程模型,它包含三個重要的組成部分。
起始信令:信令流程的觸發(fā)信令,也可以說是流程的第一條信令。
結束信令:信令流程的最后一條信令,該條信令標識流程的完結。如圖中最下面所示的結束信令1、結束信令2、……、結束信令n,這表示結束信令有多種可能。這是因為流程有可能正常結束,也有可能異常結束(比如流程失敗了),或其他的一些情況,結束信令往往不唯一。
中間信令:除起始、結束信令之外的,在網(wǎng)元間傳遞和轉換的信令。該部分信令的特點是某些信令會根據(jù)不同的組網(wǎng)、業(yè)務等情況,會條件的出現(xiàn)。鑒于這個特點,該部分信令可以分成兩大類:流程必定包含的信令和流程可能包含的信令。
依據(jù)上面的信令流程,可以映射得到的信令流程模型。該模型有起始信令、中間信令(必有)、中間信令(可有)、結束信令組。起始信令標識該流程的起始;中間信令(必有)包含該流程中必定包含的信令;中間信令(可有)包含該流程中條件出現(xiàn)的信令;結束信令組,定義了若干條與流程起始 信令對應的結束信令(每條結束信令都可能是該流程的結束)。
有了上面定義的業(yè)務流程,下面結合圖2,講解一下提取信令流程的主要步驟,如下:
步驟201、遍歷采集到的信令數(shù)據(jù)集合。
步驟202、判斷提取出的集合中的一條信令是否能和某個配置的業(yè)務信令流程的起始信令相匹配,如果不能,則繼續(xù)遍歷采集到的信令數(shù)據(jù)集合。
步驟203、如果信令是某個業(yè)務流程的起始信令,則找到與起始信令對應的結束信令組。
步驟204、遍歷結束信令組,從若干結束信令中提取出一條失敗信令,然后從信令集合中當前信令的下一條開始索引結束信令,如果沒有索引到結束信令,則繼續(xù)遍歷結束信令,直到遍歷結束。
步驟205、如果索引到了結束信令,則依據(jù)起始信令編號和結束信令編號將這一閉區(qū)間的信令全部提取出來。
步驟206、流程清洗。在流程提取前,會對多個網(wǎng)元上報的信令進行排序,排序主要的依據(jù)是單網(wǎng)元信令的上報順序,以及信令的時間戳,由于網(wǎng)元時間的不一致以及業(yè)務的復雜性(比如正在做數(shù)據(jù)業(yè)務,之間來了電話),都會導致提取的流程中可能會夾雜不是本流程的信令??梢岳弥皹I(yè)務流程中定義的信令(起始、結束信令以及中間信令)對流程進行清洗,即將流程中不在其中的信令移除。
步驟207、將清洗后的信令提取出來,并將起始、結束信令打上標記(標注哪條是起始信令、哪條是結束信令),構建信令流程。
步驟208、繼續(xù)遍歷采集到的信令數(shù)據(jù)集合(不是從結束信令開始遍歷,而是從起始信令的下一條開始),直到遍歷到最后一條信令,將所有的信令流程都提取出來為止。
在將流程提取出來的基礎上,下一步就可以辨識異常信令流程了。結合圖3,辨識的步驟如下:
步驟301、遍歷提取出來的信令流程。
步驟302、遍歷信令流程中包含起始、結束信令區(qū)間的信令。
步驟303、如果其中一條信令的名稱直接標識信令失敗,則將流程標識為異常流程。
步驟304、如果不能直接通過名稱來判斷信令是否失敗,則需要識別一下該信令是否包含原因碼,如果包含原因碼,則提取原因碼,如果不包含,則繼續(xù)遍歷流程中的信令。
步驟305、對于提取出來的原因碼,需要判斷一下該原因碼是否標識該信令失敗(因為有些是標識成功的),如果標識的是失敗,則提取信令的網(wǎng)元名(提取的方法是根據(jù)信令的方向,如果是發(fā)送的,直接提取網(wǎng)元名稱,如果是接收的,則利用md5找到關聯(lián)的發(fā)送信令,再提出網(wǎng)元名稱),用以標識流程在該網(wǎng)元處發(fā)生失敗,并將流程標識為異常流程。
步驟306、按照步驟3、4、5的方式,遍歷該流程中所有的信令。
步驟307、流程遍歷結束后,獲取該業(yè)務流程模型中定義的中間信令(必有)部分的信令。
步驟308、遍歷中間信令(必有)部分的信令。
步驟309、如果中間信令(必有)中的一條在信令流程中能夠匹配到,則繼續(xù)遍歷,如果匹配不到,則判斷該條信令的發(fā)送網(wǎng)元類型在信令流程中是否只包含一個該類型被跟蹤的網(wǎng)元,如果只有一個,則能確定該網(wǎng)元缺失信令,如果有多個,則只能確定該流程中缺失該條信令,并將流程標識為異常流程。
步驟310、待流程遍歷結束后,利用md5將發(fā)送和接收的信令關聯(lián)起來。
步驟311、在關聯(lián)的過程中辨識是否存在不能匹配的信令,或稱單點信令,如果該信令所對應的源或者目的ip是系統(tǒng)中跟蹤網(wǎng)元的ip,則說明流程異常(可能是對端的網(wǎng)元漏報了信令,也可能網(wǎng)元發(fā)了,但是信令跟蹤系統(tǒng)沒有 接收到),標記出問題的網(wǎng)元后,將該流程標識為異常流程。
步驟312、依據(jù)步驟2到步驟11,將所有流程異常流程全部識別出來。
通過上述方法,本發(fā)明可以依據(jù)網(wǎng)元上報的單條信令,提取出信令流程,并識別出異常信令流程。用戶可以通過異常信令流程,快速的定位到發(fā)生問題的網(wǎng)元以及問題產(chǎn)生的原因,能極大的提高排除問題的效率,也為日常的系統(tǒng)維護提供了很大的便利。
同時,信令流程作為信令跟蹤的基本概念,為用戶分析或者用戶間交流提供了公共的語言。
本發(fā)明提供的第一實施例如圖4所示,描述客戶端直接打開信令文件觸發(fā)流程提取和異常信令分析的流程。該流程包括以下步驟:
步驟s100、網(wǎng)管系統(tǒng)已經(jīng)采集各網(wǎng)元上報的信令并匯總為信令文件。
步驟s101、客戶端請求直接打開已經(jīng)生成的信令文件。
步驟s102、系統(tǒng)讀取信令文件并觸發(fā)異常信令識別過程。
步驟s103、進行信令流程提取過程。
步驟s104、根據(jù)異常信令索引,標識歸屬的信令流程為異常流程。
步驟s105、流程提取和識別的結果返回給界面展示單元,由界面展示單元進行進一步的渲染。
步驟s106、渲染結果以及數(shù)據(jù)返回給界面展示單元進行展示,打開信令文件流程結束。
本發(fā)明提供的第二實施例,描述服務器定時進行緩存信令分析,觸發(fā)流程提取和異常信令識別過程,客戶端查看分析結果。該流程包括以下步驟:
步驟s200、網(wǎng)管客戶端與服務器之間正常建立連接。
步驟s201、網(wǎng)管客戶端創(chuàng)建跟蹤任務,信令正常由各網(wǎng)元上報到服務器。
步驟s202、網(wǎng)管服務器緩存信令文件。
步驟s203、網(wǎng)管服務器定時對緩存信令文件進行分析處理。
步驟s204、服務器針對信令文件進行信令流程提取過程。
步驟s205、針對已經(jīng)識別的信令流程,識別異常信令,標識異常信令流程。
步驟s206、將識別結果存入數(shù)據(jù)庫。
步驟s207、網(wǎng)管客戶端請求查看服務器數(shù)據(jù)。
步驟s208、網(wǎng)管服務器返回分析后的結果返回給客戶端。
步驟s209、網(wǎng)管客戶端獲取返回分析后的結果并進行其他處理和渲染。
步驟s210、渲染結果以及數(shù)據(jù)返回給界面展示單元進行展示,客戶端查看服務器分析后的結果流程結束。
以上僅為本發(fā)明的優(yōu)選實施例,并非因此限制本發(fā)明的專利范圍,凡是利用本發(fā)明說明書及附圖內(nèi)容所作的等效結構或等效流程變換,或直接或間接運用在其他相關的技術領域,均同理包括在本發(fā)明的專利保護范圍內(nèi)。