專利名稱：在線跟蹤業(yè)務(wù)流程的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及通信領(lǐng)域，特別涉及移動通信系統(tǒng)中核心網(wǎng)設(shè)備內(nèi)部各個功能模塊之間對消息在線跟蹤的實現(xiàn)技術(shù)。
背景技術(shù)：
在通用分組無線業(yè)務(wù)(General Packet Radio Service，簡稱“GPRS”)核心網(wǎng)設(shè)備商用的過程中，需要分析某類特定用戶對性能指標的影響，以及分析核心網(wǎng)設(shè)備的運行狀況。但是，由于網(wǎng)上用戶數(shù)多，GPRS網(wǎng)絡(luò)設(shè)備復(fù)雜，各廠商手機功能實現(xiàn)不一致，給網(wǎng)上性能分析帶來了一定困難。
在這個過程中，需要對通信系統(tǒng)網(wǎng)絡(luò)設(shè)備之間以及設(shè)備內(nèi)部的消息進行跟蹤，從而獲得對各類性能影響以及設(shè)備的運行狀況等的足夠了解，以便解決相應(yīng)的問題。
目前，已有針對特定用戶的消息跟蹤技術(shù)，其具體的實現(xiàn)方式是將特定用戶在各標準接口上的消息上報到消息跟蹤臺。
圖1示出了現(xiàn)有技術(shù)處理通信系統(tǒng)對業(yè)務(wù)流程中消息跟蹤的實現(xiàn)方法。
其中A設(shè)備10、B設(shè)備11以及C設(shè)備12是移動通信網(wǎng)絡(luò)中核心網(wǎng)部分的各個諸如通用分組無線業(yè)務(wù)網(wǎng)關(guān)支持節(jié)點(GPRS Gateway SupportNode，簡稱“GGSN”)、通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(Serving GPRSSupport Node，簡稱“SGSN”)以及歸屬位置寄存器(Home Location Register，簡稱“HLR”)之類的網(wǎng)絡(luò)設(shè)備。而且，這個三個設(shè)備之間的系統(tǒng)接口都是規(guī)范的標準接口。
如圖1所示，當需要分析一個特定的由A設(shè)備10經(jīng)B設(shè)備11到達C設(shè)備12的消息流程對網(wǎng)絡(luò)性能的影響時，就有必要對該消息的處理進行跟蹤。
于是，系統(tǒng)首先在A設(shè)備10與B設(shè)備11的標準接口上將由A設(shè)備10發(fā)往B設(shè)備11的消息1上報到消息跟蹤臺。其中，消息跟蹤臺是用來顯示跟蹤到的消息結(jié)果的，它位于移動通信網(wǎng)絡(luò)的操作和維護中心。
而后，這個消息1經(jīng)過B設(shè)備11處理后轉(zhuǎn)換成為消息2，通信系統(tǒng)于是再在B設(shè)備11和C設(shè)備12的標準接口上將消息2上報到消息跟蹤臺，而對于B設(shè)備11是如何處理該消息1，以及B設(shè)備11內(nèi)部的各個子模塊處理該消息前后的信息則是現(xiàn)有技術(shù)所無法獲得的。
在實際應(yīng)用中，上述方案存在以下問題由于現(xiàn)有技術(shù)中對消息的跟蹤中主要是跟蹤系統(tǒng)網(wǎng)絡(luò)設(shè)備之間標準接口上的消息，所以只能知道設(shè)備處理相應(yīng)消息后的結(jié)果，而不知道該消息在具體設(shè)備內(nèi)部的各個模塊之間的轉(zhuǎn)換過程，而且系統(tǒng)中網(wǎng)絡(luò)設(shè)備之間的標準接口能提供的信息是非常有限的，往往對網(wǎng)絡(luò)設(shè)備的運行狀況和性能分析幫助不是很大。

發(fā)明內(nèi)容
有鑒于此，本發(fā)明的主要目的在于提供一種在線跟蹤業(yè)務(wù)流程的方法，以解決上文中提到的對消息跟蹤過程中的網(wǎng)絡(luò)設(shè)備運行狀況和性能分析困難和定位手段單一的問題，以及解決信息不足無法進行快速有效分析的問題。從而不僅實現(xiàn)對設(shè)備間消息的跟蹤，而且實現(xiàn)對系統(tǒng)設(shè)備內(nèi)部各個模塊之間處理消息前后的在線跟蹤，對設(shè)備運行狀況和性能提供更多樣、更全面的分析依據(jù)。
為實現(xiàn)上述目的，本發(fā)明提供了一種在線跟蹤業(yè)務(wù)流程的方法，包含以下步驟A業(yè)務(wù)模塊收到需要跟蹤的第一消息時，將該消息中的用戶活動信息保存至該用戶的用戶信息表中；
B所述業(yè)務(wù)模塊將所述用戶信息表封裝成第二消息，并通過消息跟蹤模塊發(fā)送至消息跟蹤臺；C當所述業(yè)務(wù)模塊處理完所述第一消息時，將更新后的用戶信息表封裝成第三消息，并通過消息跟蹤模塊發(fā)送至消息跟蹤臺。
其中，所述步驟A中，當跟蹤標志表示為需要跟蹤，并且已根據(jù)所述用戶創(chuàng)建了用戶跟蹤時，所述業(yè)務(wù)模塊判定需要跟蹤收到的消息。
所述方法還包含以下步驟D所述消息跟蹤臺調(diào)用所述業(yè)務(wù)模塊中的消息解析文件，將二進制碼流形式的所述第二和第三消息解析成可讀形式，并顯示解析結(jié)果。
所述業(yè)務(wù)模塊和所述消息跟蹤模塊位于通信設(shè)備中，所述消息跟蹤臺位于操作和維護中心。
所述通信設(shè)備是SGSN、或GGSN。
所述業(yè)務(wù)模塊是通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點中的移動性管理模塊、或會話管理模塊、或短消息處理模塊。
所述方法還包含以下步驟所述消息跟蹤臺將所述第二和第三消息全部或單獨保存為所述消息跟蹤臺可運行的文件形式，用于分析和定位。
通過比較可以發(fā)現(xiàn)，本發(fā)明的技術(shù)方案與現(xiàn)有技術(shù)的區(qū)別在于，現(xiàn)有技術(shù)處理消息跟蹤的實現(xiàn)方式是將特定用戶在各標準接口上的消息上報到消息跟蹤臺。由于現(xiàn)有技術(shù)對消息跟蹤的處理主要是集中在對網(wǎng)絡(luò)設(shè)備之間標準接口的消息跟蹤，所以只能知道其設(shè)備之間運行的結(jié)果，而不知道消息在具體設(shè)備內(nèi)部各個模塊之間的消息轉(zhuǎn)換過程，而且標準接口能提供的信息非常有限，往往對網(wǎng)絡(luò)設(shè)備運行狀況和性能分析幫助不大。
而本發(fā)明方案則是通過業(yè)務(wù)模塊、消息跟蹤模塊以及消息跟蹤臺之間的通力協(xié)作，針對需要進行跟蹤的消息，將設(shè)備內(nèi)部各業(yè)務(wù)模塊處理前后的消息以信息表方式上報，以此來實現(xiàn)對通信系統(tǒng)中網(wǎng)絡(luò)設(shè)備內(nèi)部模塊之間消息的跟蹤。
這個消息跟蹤的過程類似于用戶標準接口上消息的上報和解析，只是業(yè)務(wù)模塊通知消息跟蹤模塊的消息類型是特定的，這樣就使得消息跟蹤模塊可以根據(jù)消息的類型直接調(diào)用業(yè)務(wù)模塊中對應(yīng)的消息解析文件來將二進制碼流的消息解析成可讀的形式。
因此，本發(fā)明方案的這種針對通信系統(tǒng)中網(wǎng)絡(luò)設(shè)備內(nèi)部各個模塊之間消息跟蹤的處理，為分析網(wǎng)絡(luò)設(shè)備的運行狀況和性能提供更加細致和可靠的依據(jù)。
這種技術(shù)方案上的區(qū)別，帶來了較為明顯的有益效果，即本發(fā)明方案通過業(yè)務(wù)模塊、消息跟蹤模塊以及消息跟蹤臺的協(xié)調(diào)作用，實現(xiàn)通信系統(tǒng)中網(wǎng)絡(luò)設(shè)備內(nèi)部各個模塊對消息處理前后的跟蹤，一方面可以方便的針對特定用戶進行其內(nèi)部信息的有效獲取，而且，消息跟蹤方式的手段使得控制信息表非常直觀明了且有效，定位更加方便。另一方面，對于消息跟蹤臺上用戶信息表的消息均可以選擇全部或單個保存成維護臺可運行的文件方式，使得回顧分析定位相應(yīng)消息內(nèi)容時能夠得到很多的方便。


圖1是現(xiàn)有技術(shù)處理通信系統(tǒng)對業(yè)務(wù)流程中消息跟蹤的實現(xiàn)方法示意圖；圖2是根據(jù)本發(fā)明的一個實施例的在線跟蹤業(yè)務(wù)流程的方法原理示意圖；圖3是根據(jù)本發(fā)明的一個實施例的在線跟蹤業(yè)務(wù)流程的方法的消息傳遞示意圖。
具體實施例方式
為使本發(fā)明的目的、技術(shù)方案和優(yōu)點更加清楚，下面將結(jié)合附圖對本發(fā)明作進一步地詳細描述。
本發(fā)明方案通過對在線可控使用跟蹤功能、對可分業(yè)務(wù)進行流程控制、以及對業(yè)務(wù)流程任務(wù)處理模塊的信息以消息方式在線輸出，以此來實現(xiàn)業(yè)務(wù)流程處理模塊在線跟蹤的方法，而且對于用戶信息表消息可以以直觀的方式進行解析，方便維護人員進行分析，而對于用戶信息表則可以保存以便回顧，供日后分析、比較。
其中，通過在線可控使用跟蹤功能，使得業(yè)務(wù)流程處理模塊跟蹤標志可以在維護臺上使用命令行的方式進行控制。如果該跟蹤標志設(shè)為True，則表明進行業(yè)務(wù)流程處理模塊跟蹤；如果該標志設(shè)為False，則標明不進行用戶跟蹤。判斷是否使用跟蹤的條件是根據(jù)該用戶創(chuàng)建了用戶跟蹤與否以及是否存在業(yè)務(wù)流程處理模塊跟蹤的標志來判斷是否需將用戶信息表作為消息上報。
而對可分業(yè)務(wù)進行流程控制則是為了針對某些業(yè)務(wù)流程進行跟蹤，本發(fā)明方案可以設(shè)定特定的業(yè)務(wù)流程，只在設(shè)定的業(yè)務(wù)流程中進行業(yè)務(wù)流程處理模塊的跟蹤。
對于通信系統(tǒng)中網(wǎng)絡(luò)設(shè)備內(nèi)部各個模塊之間消息處理前后的跟蹤是通過業(yè)務(wù)模塊、消息跟蹤模塊以及消息跟蹤臺之間的協(xié)調(diào)工作來實現(xiàn)的。
下面根據(jù)本發(fā)明方案，來作具體的闡述。業(yè)務(wù)模塊進行業(yè)務(wù)流程時，在設(shè)備中均會針對每一個用戶建立一個用戶信息表，用以保存用戶的身份信息、位置信息、當前流程的信息以及和內(nèi)部接口交互的信息，并且用戶信息表根據(jù)不同流程、不同階段更新信息。從用戶信息表中可以獲取每個階段用戶的各種活動信息、以及當前處理流程的狀態(tài)。本發(fā)明就是將用戶信息表以消息方式進行上報，而上報的信息表中包含有當前用戶在各模塊處理前后不同階段的信息，以便觀察網(wǎng)絡(luò)系統(tǒng)中設(shè)備內(nèi)部處理的詳細過程，從而達到有效分析通信系統(tǒng)運行狀況的目的。
圖2示出了本發(fā)明的業(yè)務(wù)流程信息點的信息以消息方式在線輸出過程中用戶信息表跟蹤的示意圖。
如圖2所示，用戶信息表跟蹤的過程主要由業(yè)務(wù)模塊20、消息跟蹤模塊21以及消息跟蹤臺22來協(xié)同實現(xiàn)的。
其中，業(yè)務(wù)模塊20位于通信設(shè)備中，熟悉本領(lǐng)域的人員應(yīng)該知道，這里涉及的通信設(shè)備即是諸如通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點(Serving GPRSSupport Node，簡稱“SGSN”)、或通用分組無線業(yè)務(wù)網(wǎng)關(guān)支持節(jié)點(GPRSGateway Support Node，簡稱“GGSN”)之類的設(shè)備。而業(yè)務(wù)模塊可以是SGSN中的移動性管理模塊、會話管理模塊或者短消息處理模塊。
消息跟蹤模塊21也和業(yè)務(wù)模塊20一樣都是位于通信設(shè)備中的。而消息跟蹤臺22則位于操作和維護中心，用以接收信息表和處理信息解析，并為維護人員提供相關(guān)信息。
消息解析文件201則是業(yè)務(wù)模塊20提供的用以解析消息的文件，通過消息跟蹤臺調(diào)用消息解析文件把二進制消息碼流解析為可讀的形式，以方便維護人員進行維護。因為消息為二進制碼流，不進行消息解析處理維護人員無法現(xiàn)場進行分析。本發(fā)明方案提供了消息解析的功能可以以直觀的方式解析用戶信息表消息，方便維護人員進行分析。
如圖2所示，業(yè)務(wù)模塊20控制在用戶活動的各個階段將當前的用戶信息表組裝成消息發(fā)送給消息跟蹤模塊21。具體的說，當業(yè)務(wù)模塊20收到消息A，將相關(guān)信息保存在用戶信息表中，并在該消息A被處理之前，由業(yè)務(wù)模塊20控制將用戶信息表封裝成消息發(fā)送給消息跟蹤模塊21。然后，消息跟蹤模塊21將用戶信息表發(fā)送到消息跟蹤臺22。
而在業(yè)務(wù)模塊20處理完收到的消息A后，再由該業(yè)務(wù)模塊20控制將用戶信息表封裝成消息發(fā)送給消息跟蹤模塊21，而隨后消息跟蹤模塊21再將經(jīng)過業(yè)務(wù)模塊20處理后的消息所對應(yīng)的用戶信息表發(fā)送到消息跟蹤臺22。
消息跟蹤模塊21負責接收業(yè)務(wù)模塊20的跟蹤消息以及將該消息碼流發(fā)送到消息跟蹤臺22上，并調(diào)用業(yè)務(wù)模塊20提供的消息解析文件201來對消息進行解析，從而將二進制碼流形式的消息解析成可讀形式，并顯示其解析結(jié)果。這些過程都類似于用戶標準接口消息的上報和解析，只是在本專利中業(yè)務(wù)模塊20通知消息跟蹤模塊21的消息類型是特定的，如用戶信息表消息，以使得消息跟蹤模塊21可以根據(jù)消息類型直接調(diào)用業(yè)務(wù)模塊20中對應(yīng)的消息解析文件201。
下面參照圖3來具體描述本發(fā)明方案的消息跟蹤的具體流程。
如圖3所示，首先在步驟310中，業(yè)務(wù)模塊20收到一個消息B，然后對其進行判定是否需要進行消息跟蹤，具體的判定方法是根據(jù)前面所述的本發(fā)明方案中的在線可控功能，為了文章的簡明在此就不再重復(fù)敘述了。而當消息B中的跟蹤標志表示為需要跟蹤時，并且已根據(jù)用戶創(chuàng)建了用戶跟蹤時，業(yè)務(wù)模塊則判定為需要跟蹤收到的該消息B，于是業(yè)務(wù)模塊就將該消息B中的用戶活動信息保存至該用戶的用戶信息表中；隨后，進入步驟320。
在步驟320，業(yè)務(wù)模塊20將消息B所對應(yīng)的該用戶信息表封裝成消息P，并將此封裝消息P發(fā)送到消息跟蹤模塊21中。然后，在步驟330，消息跟蹤模塊21再將該封裝消息P發(fā)送至消息跟蹤臺22。
隨后，在步驟330，業(yè)務(wù)模塊20處理收到的消息B。當業(yè)務(wù)模塊20處理完成該消息B后，就在步驟340中由業(yè)務(wù)模塊20控制將更新后的用戶信息表封裝成消息Q。并進入步驟350。在步驟350，業(yè)務(wù)模塊將封裝的消息Q發(fā)送到消息跟蹤模塊21。隨后，在步驟360中，消息跟蹤模塊21再將該封裝消息Q轉(zhuǎn)發(fā)到消息跟蹤臺22。
因為消息為二進制碼流，如果不進行消息解析維護人員無法現(xiàn)場進行分析，因此必須對消息進行消息解析。于是，當消息跟蹤臺22在接收到由業(yè)務(wù)模塊20通過消息跟蹤模塊21轉(zhuǎn)發(fā)過來的封裝消息P和封裝消息Q后，便在步驟370中，消息跟蹤臺22調(diào)用業(yè)務(wù)模塊32中提供的消息解析文件來將二進制碼流的消息解析成可讀的形式。這樣，就通過消息解析，將二進制碼流的封裝消息P和封裝消息Q解析成為可讀形式，并顯示其解析結(jié)果，從而最終完成了對該業(yè)務(wù)流程的設(shè)備內(nèi)部模塊之間的消息跟蹤。
消息跟蹤臺將封裝消息P和封裝消息Q全部或單獨保存為消息跟蹤臺可運行的文件形式，用于分析和定位。這樣就可以保存回顧，供日后分析比較提供了方便。
雖然通過參照本發(fā)明的某些優(yōu)選實施例，已經(jīng)對本發(fā)明進行了圖示和描述，但本領(lǐng)域的普通技術(shù)人員應(yīng)該明白，可以在形式上和細節(jié)上對其作各種各樣的改變，而不偏離所附權(quán)利要求書所限定的本發(fā)明的精神和范圍。
權(quán)利要求
1.一種在線跟蹤業(yè)務(wù)流程的方法，其特征在于，包含以下步驟A業(yè)務(wù)模塊收到需要跟蹤的第一消息時，將該消息中的用戶活動信息保存至該用戶的用戶信息表中；B所述業(yè)務(wù)模塊將所述用戶信息表封裝成第二消息，并通過消息跟蹤模塊發(fā)送至消息跟蹤臺；C當所述業(yè)務(wù)模塊處理完所述第一消息時，將更新后的用戶信息表封裝成第三消息，并通過消息跟蹤模塊發(fā)送至消息跟蹤臺。
2.根據(jù)權(quán)利要求1所述的在線跟蹤業(yè)務(wù)流程的方法，其特征在于，所述步驟A中，當跟蹤標志表示為需要跟蹤，并且已根據(jù)所述用戶創(chuàng)建了用戶跟蹤時，所述業(yè)務(wù)模塊判定需要跟蹤收到的消息。
3.根據(jù)權(quán)利要求1所述的在線跟蹤業(yè)務(wù)流程的方法，其特征在于，所述方法還包含以下步驟D所述消息跟蹤臺調(diào)用所述業(yè)務(wù)模塊中的消息解析文件，將二進制碼流形式的所述第二和第三消息解析成可讀形式，并顯示解析結(jié)果。
4.根據(jù)權(quán)利要求1所述的在線跟蹤業(yè)務(wù)流程的方法，其特征在于，所述業(yè)務(wù)模塊和所述消息跟蹤模塊位于通信設(shè)備中，所述消息跟蹤臺位于操作和維護中心。
5.根據(jù)權(quán)利要求4所述的在線跟蹤業(yè)務(wù)流程的方法，其特征在于，所述通信設(shè)備是通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點、或通用分組無線業(yè)務(wù)網(wǎng)關(guān)支持節(jié)點。
6.根據(jù)權(quán)利要求1所述的在線跟蹤業(yè)務(wù)流程的方法，其特征在于，所述業(yè)務(wù)模塊是通用分組無線業(yè)務(wù)服務(wù)支持節(jié)點中的移動性管理模塊、或會話管理模塊、或短消息處理模塊。
7.根據(jù)權(quán)利要求3所述的在線跟蹤業(yè)務(wù)流程的方法，其特征在于，所述方法還包含以下步驟所述消息跟蹤臺將所述第二和第三消息全部或單獨保存為所述消息跟蹤臺可運行的文件形式，用于分析和定位。
全文摘要
本發(fā)明涉及通信領(lǐng)域，公開了一種在線跟蹤業(yè)務(wù)流程的方法，解決目前對消息跟蹤過程中的網(wǎng)絡(luò)設(shè)備運行狀況和性能分析困難和定位手段單一的問題。這種在線跟蹤業(yè)務(wù)流程的方法包含以下步驟A業(yè)務(wù)模塊收到需要跟蹤的第一消息時，將該消息中的用戶活動信息保存至該用戶的用戶信息表中；B業(yè)務(wù)模塊將用戶信息表封裝成第二消息，并通過消息跟蹤模塊發(fā)送至消息跟蹤臺；C當業(yè)務(wù)模塊處理完第一消息時，將更新后的用戶信息表封裝成第三消息，并通過消息跟蹤模塊發(fā)送至消息跟蹤臺。
文檔編號H04Q7/22GK1722675SQ20041007173
公開日2006年1月18日 申請日期2004年7月13日 優(yōu)先權(quán)日2004年7月13日
發(fā)明者沈穎燕, 邱雪峰, 陳靖, 楊立峰, 王輝林, 毛豪輝 申請人:華為技術(shù)有限公司