專利名稱：定位故障的方法以及業務維護平臺的制作方法
技術領域：
本發明通信技術領域，特別是一種定位故障的方法以及一種業務維護平臺。
背景技術：
電信運營商業務系統，例如客戶管理系統(CRM)、客戶維護(CustomCare)、帳單(Billing)等業務支撐系統(BSS)/運營支撐系統(OSS)，無法避免都要或多或少地開展一些業務，需要與諸如歸屬位置寄存器(HLR)/鑒權中心(AuC)、無線智能網(WIN)、移動數據業務平臺(MDSP)、短消息中心(SMSC)、語音郵箱系統(VMS)、多媒體信息服務中心(MMSC)、統一消息服務(UM)、下一代網絡(NGN)、公共電話交換網(PSTN)等網絡側的網元(NE)存在接口，以進行業務開通(Service Provisioning)，Provisioning系統就相當于介于BSS/OSS和NE之間的接口。Provisioning系統有被稱為聯機指令系統的，也有被稱為業務開通系統(ServiceProvisioning)的，本發明統一稱之為聯機指令系統。圖1給出了聯機指令系統的位置。
目前，電信運營商無法避免會存在CRM、Custom Care、Billing等多個BSS/OSS系統，或存著不同專網的BSS/OSS運營系統，這些系統都需要交叉開展業務，需要與網絡側的網元存在接口，如果每個BSS/OSS業務請求系統都與網元直接相連，而每個網元又存在不同特色的通信協議，那勢必會形成一個龐大的網狀結構，這樣不僅加大了運營商BSS/OSS系統的投入成本，同時還延長了運營商支撐新業務的進度。而且，由各個BSS/OSS系統提供的網元接口功能往往非常薄弱，不利于運營商快速地推出新業務。另外，此時的網元接口可維護性較低，如果發生異常，將很難處理。
現有聯機指令系統的模式如圖2所示。參照圖2，現有的聯機指令系統一般存在以下的特點一個網元接口對應一套獨立的程序或進程，接口與接口之間相互獨立，每個接口有內部獨立的處理邏輯。
申請人在實際使用過程中發現，由于在現有的聯機指令系統中，每個進程采用分散的方式，獨立啟動，獨立運作，各個進程之間基本沒有交互，各自處理各自網元的指令工單，所以這種聯機指令系統不可能具備統一的網管、日志管理、業務工單、指令等維護管理機制，對于運營商和系統提供商來說很難維護，而且可靠性較差。
另外，上述聯機指令系統也不可能具備統一的業務開通平臺和業務故障處理平臺，無法在該系統上直接查詢、單個/批量開通、單個/批量修改各網元的業務。這就導致局方的維護人員只有逐一的登錄到網元系統上進行故障處理，而在復雜的網絡系統中，網元非常眾多，很難逐一辨別和處理，這最終將會導致業務故障處理周期長且容易出錯。例如，客戶發現手機無法使用某業務，向局方報障，局方維護人員接收到障礙后，通過目前的聯機指令系統根本無法進行故障定位，即查詢到用戶實際在網元上的開通狀態，只能手工登錄到網元上去查看是否故障。另外，維護人員更不能直接通過該聯機指令系統進行某個業務的重新開通。
發明內容
有鑒于此，本發明實施例提出了一種定位故障的方法，用以實現簡單方便的故障定位。本發明實施例還提出了一種業務維護平臺。
本發明實施例提供了一種定位故障的方法，該方法包括接收一或多個查詢的業務工單；將所述一或多個查詢的業務工單分解為針對網元的一或多個指令工單，并將所述一或多個指令工單發送給對應的網元；根據所述對應的網元返回的結果確定故障位置和/或故障內容。
本發明實施例還提供了一種業務維護平臺，該業務維護平臺包括請求分解模塊，用于將一或多個業務工單分解為一或多個指令工單；網元適配器，用于分解、解析所述一或多個指令工單并轉換為針對網元的一或多個指令工單，以適配同一協議下不同網元之間的差異；網元前置機，用于將網元適配器轉換后的一或多個指令工單發送給對應的網元，并實現協議的通用適配。
通過本發明實施例中提供的定位故障的方法和業務維護平臺，只需要向業務維護平臺提交查詢的業務工單，該業務維護平臺將其分解為針對網元的指令工單，并發送給對應的網元，然后可以根據網元返回的結果來確定故障位置和/或故障內容，從而實現了簡單方便的故障定位技術。而且，本發明實施例提出的業務維護平臺還能夠用于查詢、修改、終止業務工單以及設置業務工單的優先級，并且還能夠直接開通業務、直接修改業務、直接處理用戶業務故障，而不需要到網元設備上處理，大大方便了操作人員的使用。由于本發明實施例具備統一、完善告警監控能力，能夠統一系統維護，減少了多余的操作，從而降低了維護工作量，有利于提高系統的穩定性。
圖1為聯機指令系統的位置示意圖；圖2表示現有聯機指令系統的模式；圖3為本發明實施例技術方案中的抽象圖；圖4為本發明實施例中定位故障的流程示意圖；圖5為本發明實施例中開通業務的流程示意圖；圖6為本發明實施例中修改業務的流程示意圖；圖7為本發明實施例中取消業務的流程示意圖；圖8為本發明實施例中的系統結構示意圖。
具體實施例方式
為使本發明的目的、技術方案和優點更加清楚，以下舉實施例對本發明進一步詳細說明。
為了解決現有技術中的缺陷，本發明實施例提供了完整的智能化業務配置方案，使得操作人員只需要向業務維護平臺發送簡單的業務工單，然后業務維護平臺將業務工單分解轉換為針對網元的指令工單，并將所述指令工單發送給對應的網元，然后根據網元返回的結果確定故障位置和/或故障內容。
下面具體描述本發明實施例的實現方案。
為了實現本發明實施例的技術方案，需要對業務、網元、指令等進行抽象。
圖3為本發明實施例中技術方案的抽象圖。
首先描述對于網元的抽象。由于網元接口很多，如果針對一個網元接口開發一套完整的定制邏輯，不僅會導致很大的人力浪費，而且成本太高。因此將網元層面細分為網元前置機層和網元適配器層。
網元前置機層是對協議的一種抽象，解決相同協議的網元連接、簽到、報文發送和獲取機制，比如網元前置機層可以分為套接字(Socket)MML、遠程登錄協議(Telnet)、文件傳輸協議(FPT)、點到點短消息協議(SMPP)、文件類型定義(DTD)XML over HTTP、簡單對象訪問協議(SOAP)1.1、SOAP1.2等等；在協議層進行同一的抽象，提供給各種采用同一協議、不同實現的網元以同一類型網元前置機。
其次是網元適配器，由于雖然采用同一種協議，但是實際報文拼接的規則、報文解析的規則、心跳機制等等差異比較大，網元適配器的存在就是適配這些差異。
經過以上兩層屏蔽后，剩下的就是可以完全配置化的網元信息，其包括兩部分網元基本信息、網元指令信息。其中，網元基本信息包括網元名稱、IP、端口(PORT)、登錄用戶名/密碼、失敗重發次數、是否需要簽到、網元啟動狀態、指令發送間隔時間、指令等待響應超時時間、同步/異步方式、連接數目等等。網元指令信息包括網元的指令、指令參數、指令與參數關系、參數枚舉值等等。這些網元信息可以直接與網元綁定，但是這種情況下每個網元都需要配置錄入對應的相關的指令信息，因此優選地將網元信息與網元模板綁定，網元模板是對采用同一種指令集的網元的一種抽象，一個網元模板下可能存在很多個網元。另外，網元適配器與網元模板是一一對應的關系。
換言之，一個網元前置機對應多個網元適配器，網元適配器適配不同網元的差異，簡明起見，在圖3中只標出一個網元適配器；網元適配器與網元模板為一一對應關系，抽象具有相同指令特性的網元；一個網元模板對應多個實際網元，這些不同的網元具備不同的基本信息。這些抽象的最終目的，就是將所有指令都可配置化，新增、修改指令只需修改配置。
接著描述對業務進行抽象。首先，說明一下業務的概念，業務是提供給上級業務請求系統使用的各種操作的名稱，如開戶業務、開通短消息業務、關閉來電顯示業務、預付費用戶充值業務等等。對于網元的指令來說，是不可隨意修改的，而業務是可以隨意更改的，具備一定的靈活性。
業務抽象的元素包括業務、業務參數、業務參數枚舉值、業務與參數之間關系、業務參數與業務參數關系等。經過抽象后，操作人員開展一個新業務，可以靈活地通過配置的方式，在業務維護平臺新增一個業務，業務包含幾個參數，這些參數可能存在為不同的類型，存在不同的值范圍。比如IMSI參數，參數類型為NumberString類型，長度為6-15；如果參數為枚舉值類型，則可以配置一下參數的枚舉值；如果業務參數存在默認值，則配置一個默認值；如果業務中兩個參數之間存在互斥關系，比如輸入MSISDN后就不允許輸入IMSI，則配置一下在該業務中兩個參數之間的互斥關系。
通過上述方式，本發明實施例完成了對提供給業務請求系統的業務的配置。
基于上述基礎，下面描述具體業務如何與正確的網元的指令相關聯，即對業務與網元指令關系抽象。
首先，在說明業務與指令之間的抽象之前，說明一下網元類型的概念。網元類型是對網元的一種分類，或者叫網元模板的一種分類，比如HLR類型可能有愛立信HLR、諾基亞HLR、西門子HLR等，它們都隸屬于同一種類型，叫HLR類型。一般來說，一種網元類型可能存在多種網元模板的網元，但一般只需要向該網元類型中的一個網元發送指令。比如開戶，需要向HLR發送指令，即需要向網元類型為HLR的網元發送指令，而HLR存在著愛立信、諾基亞、西門子等多種模板的多個網元，所以實際在發送時，只需要根據一定的規則向其中的一個發送指令，而不是多個。在實際應用中，同一種網元類型的網元會劃分有不同的號段，號段分為移動臺國際綜合業務數據網號碼(MSISDN)號段和國際移動用戶識別碼(IMSI)號段，通過MSISDN/IMSI信息就可以匹配到正確的網元。本發明實施例也可以通過其它標識來匹配到正確的網元。
接下來，分析一下業務包括指令邏輯關系的一些場景。例如，一個開戶業務存在如下的指令規則向網元類型1、網元類型2、網元類型3并行的發送指令；發送指令全部成功后，需要向網元類型4發送指令；網元類型4指令如發送失敗，則向網元類型5發送指令，發送成功則向網元類型6發送指令。
根據這樣的規則，用戶可以通過業務配置系統來映射業務與網元類型的關系，用來配置業務與這6種網元類型之間的關系以及這6種網元類型指令之間的邏輯關系。
在配置完與網元類型的映射關系后，用戶還可以根據系統提供的配置業務與具體網元模板指令映射關系的界面，來配置業務與某個具體模板指令的映射關系。同時允許這樣的場景，比如并行發送指令1、指令2，如果其中任何一個失敗，則終止執行；指令1、指令2成功后，發送指令3，指令3如果執行成功，則對應該網元模板的指令執行結束，如果失敗，則發送指令4、指令5回滾指令1、指令2的操作。實際的配置還可以更復雜，可以引入條件指令，即當業務參數的參數值為A時，發送指令1，為B時，發送指令2。另外，還可以允許這樣的方式，指令2的執行，需要從指令1執行的返回結果中取值，取值后賦給指令2的某個參數，進行發送，這種情況可以成為交互指令。
在能夠配置業務與指令關系基礎上，本發明實施例還能配置業務參數與指令參數的關系，能夠讓業務參數的值賦給指令參數。當然，對于業務參數枚舉值，也可以配置與指令參數枚舉值之間的關系，形成不同的映射關系。
通過以上三點的抽象，使得用戶在新增業務時，可以智能的配置業務，靈活的設置回滾、條件、交互、并行、串行等邏輯，使得新增業務變成了一種具備友好操作界面的配置性操作，從而向操作人員提供了簡單的業務開通模式，降低了對操作人員專業知識的要求。
當然，為了具備良好的可操作性，業務配置還會提供給用戶被配置業務的校驗功能，由系統自動校驗配置業務工單的正確性，避免錯誤配置。例如，通過處理一個業務請求，判斷根據該業務請求所完成的配置能否正確實現該業務請求的目的，從而校驗其正確性。
另外，本發明實施例還進一步對業務請求系統進行抽象，從而可以對于業務請求系統的業務權限、號段權限、接入方式、接入IP限制進行管理，同時還可自動設置某個業務參數對應到該業務請求系統的默認值，使得業務請求系統在發請求時盡量減少參數的填寫，由業務維護平臺對各種復雜參數進行屏蔽，達到只需要填寫MSISDN和/或IMSI就能開通業務的程度。
對于統一的業務維護平臺要基于靈活的、智能化的業務配置，其具體實現如下首先是對于業務請求抽象化。對于所有業務請求系統下發的業務請求，對應為一條業務工單，業務工單中包含業務工單序列號、業務碼(Code)、參數值列表(List)、優先級、當前狀態、下發時間、執行時間、完成時間、業務工單處理返回碼、返回結果信息等信息。業務工單標識一個業務請求。
其次，對于指令請求抽象化。對于所有實際發送到網元的一條指令，對應為一條指令工單，指令工單對應為業務工單分解后得到的實際發送到網元的指令。指令工單包含業務工單序列號、指令序號、指令標識(ID)、網元類型ID、網元模板ID、網元ID、宏指令格式、實際指令等等。其中，宏指令格式實際為一種“參數1＝值1，參數2＝值2，...”的格式，是業務工單在分解后將業務參數的值逐個的賦給指令參數，同時提供給網元適配器進行實際指令的拼接。
下面描述業務工單的提交。如上所述，所有的業務都是配置的業務，那么業務維護平臺根據這些配置，可以自動化生成一個頁面，頁面中列出該業務的所有參數，同時載入參數值的類型、范圍及參數與參數之間的各種關系，包括互斥、依賴等等，比如輸入A參數，則不允許輸入B參數，B參數自動被禁止掉，又比如輸入C參數，D參數的值自動根據C的值進行計算，從而自動獲取D參數的值等等。
在輸入參數時，可以自動提醒該參數的相關信息，可以預覽發送的業務工單、指令工單；通過這種方式，可以提交業務工單，在轉化為指令工單后，發送到任何網元上，進行業務的開通、修改、取消，業務的查詢，在業務請求處理結束后，可以同步的獲取請求的執行結果，處理各種網元的用戶故障。
使用該功能，在不使用網元客戶端登錄到網元的情況下，用戶可以開通任何網元接口能夠支持的業務，對于維護人員來說節省了大量的時間，特別是各種不同的網元對應不同的客戶端、網元個數比較多時。另外，該功能可以屏蔽了很多網元指令繁瑣的參數配置，可操作性較佳。
接著描述指令請求的發送。與業務工單類似，對于指令同樣也都是配置的業務，根據這些配置，也可以自動化生成一個開通的界面，進行指令工單的單獨發送，這樣可以單個的發送任何網元的任何指令到網元，而不必像業務工單一樣，在配置業務之后才能下發請求。
最后描述業務請求指令請求監控。在能下發的基礎上，系統同時還需基本控制的能力，具體可包括可以查詢到各種業務工單、指令工單，其查詢條件可以任意組合化；可以終止業務工單、指令工單，可以單個提交、批量提交業務工單、指令工單，可以重新設置業務工單、指令工單的優先級，當然也可以看到業務工單的詳細信息以及指令工單的詳細信息。
根據上述設置，本發明實施例中從業務請求系統提交業務工單到最終定位故障的過程如圖4所示。
參照圖4，本發明實施例中定位故障的方法包括以下步驟步驟101，運營商需要進行故障定位，操作人員通過諸如BOSS等業務請求系統登錄到業務維護平臺，并提交查詢的業務工單。
本發明實施例中的業務維護平臺可以提供包括文件接口、Java應用程序接口(API)、socket MML接口、數據庫接口、會話描述協議(SDP)接口、遠程登錄Telnet接口等的請求接口。
步驟102，業務維護平臺檢查登錄的用戶名、密碼、IP地址是否正確，如果正確，則執行步驟103及其后續步驟；否則拒絕當前的登錄，業務維護平臺還可以進一步提示用戶重新登錄。
步驟103，業務維護平臺根據已定義的格式，檢查來自業務請求系統的業務工單的格式是否正確，如果正確，則執行步驟104及其后續步驟；否則停止當前業務工單，并可以進一步提示用戶重新提交業務工單。
步驟104，業務維護平臺根據業務請求系統與業務的關系，檢查業務請求系統是否具有該業務的權限，如果有，則執行步驟105及其后續步驟；否則停止當前業務工單，并可以進一步提示用戶。
步驟105，業務維護平臺根據業務工單中所包含的號碼段，檢查業務請求系統是否具有號碼權限，如果有，則執行步驟106及其后續步驟；否則停止當前業務工單，并可以進一步提示用戶。
上述步驟102至步驟105為對業務請求系統進行鑒權的過程，雖然這里只給了上述幾種鑒權內容，但是本發明實施例的保護范圍并不局限于此，另外，上述步驟102至步驟105的先后次序也可以任意變換。
步驟106，業務維護平臺根據預先設置的數據，將業務工單分解為指令工單。
進一步，如果所述業務工單包括指令工單之間的邏輯關系，那么在分解過程中會得到該邏輯關系。
步驟107，業務維護平臺通過網元適配器將分解出的指令工單轉換為針對網元的指令工單，并向對應的網元發送指令工單，并等待網元的響應，即處理結果。
本步驟中的轉換主要包括根據業務與不同類型網元的關系，將分解出的指令工單轉換為針對不同類型網元的指令工單，然后根據同一類型網元中的具體網元即網元模板以及指令的參數，將針對該類型網元的指令工單轉換為針對所述網元的指令工單。
進一步，如果存在指令工單之間的邏輯關系，那么業務維護平臺將進一步根據所述邏輯關系將指令工單發送給對應的網元。
步驟108，根據返回的結果判斷故障位置、和/或確定故障內容。
這樣，通過本實施例就能夠簡單方便地實現故障定位，而不需要操作人員到網元設備上去處理，極大地方便了操作人員的使用，降低了維護工作量。
在定位故障之后，可以根據故障位置和故障內容，形成更改后的開通的業務工單或者形成新的開通的業務工單，然后重新開通業務，從而解決故障。圖5為開通業務的流程示意圖。參照圖5，該流程包括以下步驟步驟201，操作人員通過諸如BOSS等業務請求系統登錄到業務維護平臺，并發送開通的業務工單。
步驟202，業務維護平臺根據預先設置的數據，將業務工單分解為指令工單。此時，業務維護平臺可以對業務請求系統進行鑒權，也可以不進行鑒權。
進一步，如果所述業務工單包括指令工單之間的邏輯關系，那么在分解過程中會得到該邏輯關系。
步驟203，業務維護平臺通過網元適配器將分解出的指令工單轉換為針對網元的指令工單，并向對應的網元發送指令工單。
本步驟中的轉換主要包括根據業務與不同類型網元的關系，將分解出的指令工單轉換為針對不同類型網元的指令工單，然后根據同一類型網元中的具體網元即網元模板以及指令的參數，將針對該類型網元的指令工單轉換為針對所述網元的指令工單。
進一步，如果存在指令工單之間的邏輯關系，那么業務維護平臺將進一步根據所述邏輯關系將指令工單發送給對應的網元。
在上述流程中發送指令工單之后，業務維護平臺還可以進一步校驗所述業務工單是否正確，例如對所要實現的業務進行模擬測試。如果正確，則返回給業務請求系統；否則，將不正確的信息返回給業務請求系統。
在定位了故障之后，也可以根據故障位置和故障內容，形成修改的業務工單，然后修改業務，從而解決故障。圖6為修改業務的流程示意圖。參照圖6，該流程包括以下步驟步驟301，操作人員通過諸如BOSS等業務請求系統登錄到業務維護平臺，并發送修改的業務工單。
步驟302，業務維護平臺根據預先設置的數據，將業務工單分解為指令工單。此時，業務維護平臺可以對業務請求系統進行鑒權，也可以不進行鑒權。
進一步，如果所述業務工單包括指令工單之間的邏輯關系，那么在分解過程中會得到該邏輯關系。
步驟303，業務維護平臺通過網元適配器將分解出的指令工單轉換為針對網元的指令工單，并向對應的網元發送指令工單。
本步驟中的轉換主要包括根據業務與不同類型網元的關系，將分解出的指令工單轉換為針對不同類型網元的指令工單，然后根據同一類型網元中的具體網元即網元模板以及指令的參數，將針對該類型網元的指令工單轉換為針對所述網元的指令工單。
進一步，如果存在指令工單之間的邏輯關系，那么業務維護平臺將進一步根據所述邏輯關系將指令工單發送給對應的網元。
在上述流程中發送指令工單之后，業務維護平臺還可以進一步校驗所述業務工單是否正確，例如對所要實現的業務進行模擬測試。如果正確，則返回給業務請求系統；否則，將不正確的信息返回給業務請求系統。
在定位了故障之后，還可以根據故障位置和內容，形成取消的業務工單，然后取消業務，從而解決故障。圖7為取消業務的流程示意圖。參照圖7，該流程包括以下步驟步驟301，操作人員通過諸如BOSS等業務請求系統登錄到業務維護平臺，并發送取消的業務工單。
步驟302，業務維護平臺根據預先設置的數據，將業務工單分解為指令工單。此時，業務維護平臺可以對業務請求系統進行鑒權，也可以不進行鑒權。
進一步，如果所述業務工單包括指令工單之間的邏輯關系，那么在分解過程中會得到該邏輯關系。
步驟303，業務維護平臺通過網元適配器將分解出的指令工單轉換為針對網元的指令工單，并向對應的網元發送指令工單。
本步驟中的轉換主要包括根據業務與不同類型網元的關系，將分解出的指令工單轉換為針對不同類型網元的指令工單，然后根據同一類型網元中的具體網元即網元模板以及指令的參數，將針對該類型網元的指令工單轉換為針對所述網元的指令工單。
進一步，如果存在指令工單之間的邏輯關系，那么業務維護平臺將進一步根據所述邏輯關系將指令工單發送給對應的網元。
在上述流程中發送指令工單之后，業務維護平臺還可以進一步校驗所述業務工單是否正確，例如對所要實現的業務進行模擬測試。如果正確，則返回給業務請求系統；否則，將不正確的信息返回給業務請求系統。
圖8為本發明實施例中業務維護平臺的結構示意圖。
如圖8所示業務維護平臺至少包括請求分解模塊、網元適配器以及網元前置機，還可以進一步包括請求接口模塊、請求鑒權模塊、請求處理模塊等。
其中，請求分解模塊將業務工單分解為各個指令工單，并將指令工單發送給網元適配器。網元適配器分解、解析所述指令工單，并轉換為針對網元的指令工單，從而適配同一協議下不同網元之間的差異。網元前置機則將網元適配器轉換后的指令工單發送給對應的網元，并實現協議的通用適配。
另外，如果提交的是指令工單，那么請求分解模塊通過網元適配器將所述指令工單發送給網元前置機，網元前置機將指令工單發送給對應的網元。
業務維護平臺還進一步包括請求處理模塊，該請求處理模塊將分解后的指令工單形成隊列，并提供給網元適配器。進一步，如果請求分解模塊還分解出指令工單之間的邏輯關系，那么請求處理模塊根據該邏輯關系，將指令工單提供給網元適配器。請求處理模塊還可以將網元的處理結果回寫到指令工單和/或業務工單中，以及將所述處理結果返回給業務請求系統。該請求處理模塊還能夠查詢、終止所述業務工單、指令公擔，以及設置所述業務工單、指令工單的優先級。
業務維護平臺還進一步包括請求接口模塊。該請求接口模塊用于接收來自業務請求系統的業務工單。根據需要，該請求接口模塊可以包括文件接口、Java應用程序接口(API)、socket MML接口、數據庫接口、SDP接口、Telnet接口等等。各種接口用于接收相應渠道的業務工單。例如數據庫接口接收數據庫渠道的業務工單，Telnet接口接收Telnet渠道的業務工單。
進一步，業務維護平臺還可以包括請求鑒權模塊，該請求鑒權模塊用于對業務請求系統進行鑒權。根據需要，請求鑒權模塊可以包括用于檢查登錄的用戶名、密碼和/或IP地址的第一檢查單元；用于檢查所述業務工單的格式是否正確的第二檢查單元；用于檢查業務請求系統的業務權限的第三檢查單元；用于檢查業務請求系統的號碼權限的第四檢查單元，等等。
繼續參考圖8，圖8中還畫出了業務請求系統以及網元。由于篇幅所限，圖8中的業務請求系統只例示了帳單&客戶維護系統、CRM系統、網絡自維護(Web self-care)系統，網元也只例示了HLR、VMS、AAA、IN等。但是，本領域的普通技術人員顯然可以看出，本發明實施例并不局限于所例示的內容。
操作人員只需要向本實施例中的業務維護平臺提交查詢的業務工單，該業務維護平臺將其分解為針對網元的指令工單，并發送給對應的網元，然后可以根據網元返回的結果來確定故障位置和/或故障內容，從而實現了簡單方便的故障定位技術，而不需要操作人員到網元設備上去處理，極大地方便了操作人員的使用，降低了維護工作量。
以上所述僅為本發明的較佳實施例而已，并不用以限制本發明，凡在本發明的精神和原則之內，所作的任何修改、等同替換、改進等，均應包含在本發明的保護范圍之內。
權利要求
1.一種定位故障的方法，其特征在于，該方法包括接收一或多個查詢的業務工單；將所述一或多個查詢的業務工單分解為針對網元的一或多個指令工單，并將所述一或多個指令工單發送給對應的網元；根據所述對應的網元返回的結果確定故障位置和/或故障內容。
2.根據權利要求1所述的方法，其特征在于，該方法進一步包括對提交所述一或多個查詢的業務工單的業務請求系統進行鑒權的步驟。
3.根據權利要求2所述的方法，其特征在于，所述對業務請求系統進行鑒權的步驟包括檢查登錄的用戶名、密碼和/或IP地址；和/或檢查所述一或多個業務工單的格式是否正確；和/或檢查業務請求系統的業務權限；和/或檢查業務請求系統的號碼權限。
4.根據權利要求2所述的方法，其特征在于，所述對業務請求系統進行鑒權的步驟包括根據所述一或多個業務工單中的移動臺國際綜合業務數據網號碼MSISDN和/或國際移動用戶識別碼IMSI，檢查業務請求系統的號碼權限。
5.根據權利要求1所述的方法，其特征在于，該方法進一步包括根據故障位置和/或故障內容，修復所述故障。
6.根據權利要求1所述的方法，其特征在于，該方法進一步包括接收根據所述故障位置和/或故障內容生成的一或多個更正后的開通的業務工單，將所述一或多個開通的業務工單分解為針對網元的一或多個指令工單，并將所述一或多個指令工單發送給對應的網元；和/或接收根據所述故障位置和/或故障內容生成的一或多個修改的業務工單，將所述一或多個修改的業務工單分解為針對網元的一或多個指令工單，并將所述一或多個指令工單發送給對應的網元；和/或接收根據所述故障位置和/或故障內容生成的一或多個取消的業務工單，將所述一或多個取消的業務工單分解為針對網元的一或多個指令工單，并將所述一或多個指令工單發送給對應的網元。
7.根據權利要求1或6所述的方法，其特征在于，該方法進一步包括查詢所述一或多個業務工單；和/或終止所述一或多個業務工單；和/或設置所述一或多個業務工單的優先級。
8.根據權利要求1所述的方法，其特征在于，該方法進一步包括向業務維護平臺提交一或多個指令工單；業務維護平臺將所述一或多個指令工單發送給對應的網元。
9.根據權利要求8所述的方法，其特征在于，該方法進一步包括查詢所述一或多個指令工單；和/或終止所述一或多個指令工單；和/或設置所述一或多個指令工單的優先級。
10.一種業務維護平臺，其特征在于，該業務維護平臺包括請求分解模塊，用于將一或多個業務工單分解為一或多個指令工單；網元適配器，用于分解、解析所述一或多個指令工單并轉換為針對網元的一或多個指令工單，以適配同一協議下不同網元之間的差異；網元前置機，用于將網元適配器轉換后的一或多個指令工單發送給對應的網元，并實現協議的通用適配。
11.根據權利要求10所述的業務維護平臺，其特征在于，該業務維護平臺進一步包括請求接口模塊，用于接收來自業務請求系統的一或多個業務工單，并轉發給所述請求分解模塊。
12.根據權利要求11所述的業務維護平臺，其特征在于，所述請求接口模塊包括文件接口、和/或Java應用程序接口API、和/或套接字模塊管理語言MML接口、和/或數據庫接口、和/或會話描述協議SDP接口、和/或遠程登錄Telnet接口。
13.根據權利要求10所述的業務維護平臺，其特征在于，該業務維護平臺進一步包括請求鑒權模塊，用于對提交所述一或多個業務工單的業務請求系統進行鑒權。
14.根據權利要求13所述的業務維護平臺，其特征在于，所述請求鑒權模塊包括第一檢查單元，用于檢查登錄的用戶名、密碼和/或IP地址；和/或第二檢查單元，用于檢查所述一或多個業務工單的格式是否正確；和/或第三檢查單元，用于檢查業務請求系統的業務權限；和/或第四檢查單元，用于檢查業務請求系統的號碼權限。
15.根據權利要求10所述的業務維護平臺，其特征在于，該業務維護平臺進一步包括業務處理模塊，該業務處理模塊用于查詢所述一或多個業務工單、和/或終止所述一或多個業務工單、和/或設置所述一或多個業務工單的優先級。
16.根據權利要求10所述的業務維護平臺，其特征在于，所述請求分解模塊進一步用于將收到的一或多個指令工單通過網元適配器發送給網元前置機。
17.根據權利要求16所述的業務維護平臺，其特征在于，該業務維護平臺進一步包括業務處理模塊，該業務處理模塊用于查詢所述一或多個指令工單、和/或終止所述一或多個指令工單、和/或設置所述一或多個指令工單的優先級。
全文摘要
本發明公開了一種定位故障的方法，該方法包括接收一或多個查詢的業務工單；將一或多個查詢的業務工單分解為針對網元的一或多個指令工單，并將所述一或多個指令工單發送給對應的網元；根據所述網元返回的結果確定故障位置和/或故障內容。本發明還公開了一種業務維護平臺。通過本發明提供的技術方案，只需要向業務維護平臺提交查詢的業務工單，該業務維護平臺將其分解為針對網元的指令工單，并發送給對應的網元，然后可以根據網元返回的結果來確定故障位置和/或故障內容，從而實現了簡單方便的故障定位技術。而且，本發明實施例提出的業務維護平臺還能夠用于查詢、修改、終止業務工單以及設置業務工單的優先級。
文檔編號G06F17/30GK101022362SQ20071008695
公開日2007年8月22日 申請日期2007年3月27日 優先權日2007年3月27日
發明者孫偉 申請人:華為技術有限公司