通信網絡中業務能力交互管理系統及其方法
2023-12-04 23:27:46 1
專利名稱：通信網絡中業務能力交互管理系統及其方法
技術領域：
本發明涉及通信領域，特別涉及通信網絡中業務交互能力管理的實現技術。
背景技術：
網際協議多媒體子系統(IP Multimedia Subsystem，簡稱「IMS」)是第三代移動通信合作夥伴項目(3rd Generation Partnership Project，簡稱「3GPP」)R5階段提出的提供網際協議(Internet Protocol，簡稱「IP」)多媒體業務的子系統。它採用分組域為其上層控制信令和媒體傳輸的承載通道，並引入會話初始協議(Session Initial Protocol，簡稱「SIP」)作為業務控制協議，利用SIP簡單、易擴展、媒體組合方便的特點，通過將業務控制與承載控制分離提供豐富的多媒體業務，是業界普遍認同的解決移動和固定網絡融合的理想方案和發展方向。
IMS網絡架構中的主要功能實體包括控制用戶註冊、會話等功能的呼叫會話控制功能實體(Call Session Control Function，簡稱「CSCF」)、集中管理用戶籤約數據的歸屬用戶伺服器(Home Subscriber Server，簡稱「HSS」)、提供各種業務邏輯控制功能的應用伺服器(Application Server，簡稱「AS」)，其它還有多媒體資源控制功能實體(Multimedia Resource Control Function，簡稱「MGFC」)、策略判決功能實體(Policy Decision Function，簡稱「PDF」)等。其中CSCF按照角色功能又分為代理CSCF(Proxy-CSCF，簡稱「P-CSCF」)、查詢CSCF(Interrogating-CSCF，簡稱「I-CSCF」)、服務CSCF(Serving-CSCF，簡稱「S-CSCF」)等類型，在邏輯功能上分別完成SIP會話路由中不同的功能，在物理上可以合一也可以分置。用戶通過當前所在地代理節點P-CSCF接入IMS，會話和業務觸發控制及與AS的業務控制交互則由其註冊地的歸屬域服務節點S-CSCF完成，而I-CSCF則起到路由查詢的作用。
IMS的提出是為了基於IP向用戶提供更為優質、廉價的多媒體業務和應用。AS在業務提供過程中扮演了業務執行者的角色。業務的提供過程可分為下列四個步驟(這裡假設從會話的發起側考慮)1)IMS業務檔案的下載，在用戶註冊的過程中，一個包含業務和用戶相關數據的業務檔案由HSS下載到服務於此用戶S-CSCF中。業務檔案中的初始過濾準則，包含了是否將用戶的請求路由到相關的AS的觸發信息。在這裡，觸發信息可能是根據請求消息的請求URI(例如一個語音信箱[email protected])或請求的類型(如立即消息的MESSAGE請求)等來制定。
2)用戶請求的生成，用戶需要某種業務時，利用自己的設備生成相關的請求。例如，用戶想要建立一個語音通話。他利用UE生成一個INVITE請求(包含請求URI，媒體描述等信息)，這條請求經P-CSCF，到達服務於他的S-CSCF。
3)AS的選擇，用戶的請求到達S-CSCF後，S-CSCF檢索與請求的發起者匹配的業務檔案。根據業務檔案中的初始過濾準則，S-CSCF決定將請求路由到相應的AS或是直接進行轉發。
4)AS執行相關的服務，在收到請求後，AS開始執行相關的服務。為了開展服務，AS可以工作在以下四種模式終止UA-在這種模式下，AS充當了UE。比如，在消息類業務中，假設消息的接收方設置了某種過濾的準則，當其得到滿足時，AS可能會代表接收方生成一個最終響應這時AS是作為一個SIP UA。
CSCF不再需要處理業務邏輯，而是通過基於規則的業務觸發機制，根據用戶的籤約數據的初始過濾規則(initial Filtering Constraint，簡稱「iFC」)，由CSCF分析並觸發到規則指定的應用伺服器，由應用伺服器完成業務邏輯處理。這樣的方式下，使得IMS成為了一個真正意義上的控制層設備，與業務的藕合降低到最小。ISC接口基於SIP這一唯一的協議，這樣更有利於業務的開放，同時由於IMS與業務做到了高度的獨立，為新增業務而進行控制層設備大範圍網絡升級的情況將得到根本改觀，業務的快速推出成為可能。
IMS作為下一代電信網絡體系架構，必然是一種多業務的應用架構，在多業務應用的情況下，必然產生多種業務之間的協同性和一致性問題，先有的iFC觸發機制所能解決的業務交互管理問題顯然已經不能勝任將來多網融合、多業務種類並行的情況。多業務交互衝突所存在的問題不能得到解決，則嚴重阻礙下一代通信網絡的演進。
目前業界提出的實現業務能力交互管理(Service Capability InteractionManager，簡稱「SCIM」)的功能實體，也被形象地稱為業務經紀人(servicebroker)。所謂的Service broker的作用，就是提供多業務融合，解決多業務間的交互和可能出現的衝突問題，service broker的概念在IMS域內和域外都有所應用，但根本的焦點還是解決IMS域內各個AS的業務交互或衝突問題。到目前為止，service broker已經被引入了3GPP的相應規範，在OSA GW的相應規範中也有所體現。service broker的邏輯功能，可以位於AS上，也可以作為獨立邏輯實體，3GPP引入SCIM，其位於AS上，其主要的作用就是完成service broker的功能。
目前3GPP還沒有對service broker或SCIM給出具體的完整規範，各個主流廠家也還沒有給出具體的技術實現。
發明內容
有鑑於此，本發明的主要目的在於提供一種通信網絡中業務能力交互管理系統及其方法，使得通信網絡中多業務交互和衝突問題得到解決，實現多業務能力交互管理功能。
為實現上述目的，本發明提供了一種通信網絡中業務能力交互管理系統，包含至少一個仲裁者模塊和一個管理者模塊，所述仲裁者模塊用於在受本次呼叫產生的消息觸發並獲得控制權後，根據預先配置的規則和通過與所述管理者模塊交互得到的本次呼叫相關信息，對本次呼叫產生的消息進行處理，並對本次呼叫產生的交互業務進行仲裁；所述管理者模塊用於管理所有呼叫相關信息，管理控制權的轉交，通過與所述仲裁者模塊交互以更新本次呼叫相關信息並向所述仲裁者提供查詢。
其中，所述仲裁者模塊對本次呼叫產生的交互業務進行仲裁時，修改本次呼叫產生的消息，並轉發給目的網元，然後修改所述業務的狀態，並移交控制權給對應的應用伺服器。
此外在所述系統中，所述應用伺服器根據所對應的業務的狀態決定業務的動作，所述業務的狀態包含懸掛、嵌套、中斷、互斥，其中，當兩個交互業務的關係為嵌套且第一個業務嵌套在第二個業務中時，第一個業務處於嵌套狀態並執行，第二個業務處於懸掛狀態並暫停；當兩個交互業務的關係為中斷且第一個業務中斷第二個業務時，第一個業務處於中斷狀態並執行，第二個業務處於懸掛狀態並暫停；當兩個交互業務的關係為互斥且第一個業務優先級高於第二個業務時，執行第一個業務，並終止第二個業務。
此外在所述系統中，所述管理者模塊還用於給所述仲裁者模塊配置規則、記錄呼叫處理信息，並決定控制權在所述仲裁者模塊及應用伺服器之間轉交。
此外在所述系統中，所述管理者模塊還用於管理呼叫相關信息，包含呼叫的處理過程、呼叫的業務拓撲結構、呼叫的註冊業務信息、和呼叫的處理規則。
此外在所述系統中，所述仲裁者通過執行預先配置的腳本，對本次呼叫產生的交互業務進行仲裁。
此外在所述系統中，所述仲裁者用於在獲得控制權後，執行腳本進行仲裁，先根據本次呼叫產生的消息和待仲裁業務，查找二維規則表，根據表項中規則條件與本次呼叫相關信息匹配結果，執行仲裁。
此外在所述系統中，所述管理者模塊控制所述仲裁者模塊的產生與消亡，所述仲裁者模塊在與其相關的消息觸發時產生，在與其相關的交互業務終止後消亡。
本發明還提供了一種通信網絡中業務能力交互管理方法，包含步驟A由本次呼叫產生的消息觸發，對應仲裁者模塊獲得控制權；B該仲裁者模塊與所述管理者模塊交互，得到本次呼叫相關信息；C該仲裁者模塊根據預先配置的規則及本次呼叫相關信息，對本次呼叫產生的消息進行處理，並對本次呼叫產生的交互業務進行仲裁；D所述管理者模塊更新本次呼叫相關信息。
其中，所述步驟C包含以下子步驟C1所述仲裁者模塊根據預先配置的規則及本次呼叫相關信息進行仲裁；C2所述仲裁者模塊修改本次呼叫產生的消息，並轉發給目的網元；C3所述仲裁者模塊修改所述業務的狀態，並移交控制權給對應的應用伺服器。
此外在所述方法中，所述步驟C3進一步包含以下子步驟
所述應用伺服器根據所對應的業務的狀態決定業務的動作，所述業務的狀態包含懸掛、嵌套、中斷、互斥，其中，當兩個交互業務的關係為嵌套且第一個業務嵌套在第二個業務中時，第一個業務處於嵌套狀態並執行，第二個業務處於懸掛狀態並暫停；當兩個交互業務的關係為中斷且第一個業務中斷第二個業務時，第一個業務處於中斷狀態並執行，第二個業務處於懸掛狀態並暫停；當兩個交互業務的關係為互斥且第一個業務優先級高於第二個業務時，執行第一個業務，並終止第二個業務。
此外在所述方法中，還包含步驟所述管理者模塊預先給所述仲裁者模塊配置規則，在呼叫過程中記錄該呼叫的處理信息，並決定控制權在所述仲裁者模塊及應用伺服器之間轉交。
此外在所述方法中，所述管理者模塊所管理的呼叫相關信息包含呼叫的處理過程、呼叫的業務拓撲結構、呼叫的註冊業務信息、和呼叫的處理規則。
此外在所述方法中，所述步驟C中所述仲裁者通過執行預先配置的腳本，對本次呼叫產生的交互業務進行仲裁。
此外在所述方法中，所述步驟C中所述仲裁者在獲得控制權後，執行腳本進行仲裁，先根據本次呼叫產生的消息和待仲裁業務，查找二維規則表，根據表項中規則條件與本次呼叫相關信息匹配結果，執行仲裁。
此外在所述方法中，還包含以下步驟所述管理者模塊控制所述仲裁者模塊的產生與消亡，使得所述仲裁者模塊在與其相關的消息觸發時產生、在與其相關的交互業務終止後消亡。
此外在所述方法中，在預先配置規則時包含以下步驟首先對所有業務進行分類管理，使得不同類業務之間不存在交互；再對同一類業務進行特徵分析，獲得任意兩個業務之間的交互關係；
根據交互關係配置規則。
通過比較可以發現，本發明的技術方案與現有技術的主要區別在於，通過設置service broker邏輯功能，處理AS之間的業務交互，屏蔽交互對AS產生的影響，保證AS的獨立性，並實現多業務交互的管理功能；在service broker中設置動態產生和消亡的仲裁者和全局管理者模塊，仲裁者用於負責對應AS間的業務交互仲裁，管理者負責呼叫相關信息的維護，管理控制權的移交，並提供仲裁者查詢信息，配置仲裁規則；通過業務分類管理、特徵分析、生成規則實現一種通用的預先配置規則的方法，解決多業務情況下的仲裁規則配置問題；引入業務狀態轉移機制和業務交互模型，包括懸掛、嵌套、中斷和互斥等狀態，和基於這些狀態所建立的解決多業務交互的實現機制；通過預置的處理腳本和查表、規則匹配機制來簡化仲裁的複雜邏輯，實現提高處理效率。
這種技術方案上的區別，帶來了較為明顯的有益效果，即結合IMS的特徵，針對3GPP的應用業務架構，提出IMS域內service broker的一種實現方案，解決多業務間的交互和衝突，保持各個AS的獨立性，多業務間的一致性和協調性。對service broker的邏輯功能給出了一種有效的實現機制，基於這種機制，使得service broker的業務邏輯處理有序化，規則化，解決複雜的多業務交互處理問題，為IMS的多業務應用提供了基本的解決方法；其中通過仲裁者和管理者功能的劃分簡化了系統實現難度，通過業務狀態轉移機制的建模明確了交互問題解決方式，通過仲裁者的動態產生和消亡機制提高系統處理資源利用率，通過用腳本描述規則來簡化系統邏輯結構、提高系統執行效率，通過規則生成的通用化方法提高業務能力交互管理系統的通用性和可擴展性。
圖1是本發明的業務交互能力管理系統的基本結構圖；圖2是根據本發明的第一實施方式的業務交互能力管理系統的基本框架圖；圖3是根據本發明的第三實施方式的嵌套業務交互處理流程圖；圖4是根據本發明的第三實施方式的互斥業務交互處理流程圖；圖5是根據本發明的第四實施方式的業務交互能力管理方法流程圖。
具體實施例方式
為使本發明的目的、技術方案和優點更加清楚，下面將結合附圖對本發明作進一步地詳細描述。
本發明結合IMS的特徵，針對3GPP的應用業務架構，提出IMS域內service broker的一種實現方案，解決多業務間的交互和衝突，保持各個AS的獨立性，多業務間的一致性和協調性。基於一種新定義的機制，使得servicebroker的業務邏輯處理有序化，規則化。
基於該問題的要求，為了使得AS獨立，本發明通過設置專門處理業務交互問題的service broker層，由該層統一處理業務交互所引發的問題，屏蔽交互對單個AS的影響，使得業務交互或衝突問題對AS透明。圖1是本發明的給出SCIM系統的基本構架。
在S-CSCF層與AS層之間存在service broker邏輯功能，而且任意兩個AS之間的交互均經過service broker邏輯功能實現，由service broker對AS的操作完成AS業務交互或衝突問題的處理，保證AS獨立性。
本發明的關鍵在於service broker邏輯功能的具體實現及其與其他網絡功能實體的交互體制的建立。本發明設置至少一個仲裁者模塊和一個管理者模塊來實現service broker邏輯功能實體。其中任意一個仲裁者都是唯一對應於兩個AS之間，即專門解決兩個AS之間的交互問題，而管理者則作為全局問題的管理角色，記錄呼叫全程處理信息，配置仲裁者具體規則，負責管理控制權轉交給某一個仲裁者，由仲裁者去執行。
當消息一開始觸發到service broker層，該層產生對應的仲裁者對其處理，仲裁者對消息的處理是先將其上報給管理者，得到控制權後進行仲裁，然後轉發給AS，AS處理過程中產生的消息將由對應仲裁者處理，消息使得控制權轉交給對應的仲裁者，該仲裁者查詢管理者中各種信息進行處理，完成業務交互，並把控制權給新的AS，依次類推。
可見，核心步驟在於通過發生消息的方式使得控制權在AS與仲裁者間轉交，當發生業務交互時，仲裁者先與管理者交互，然後根據預先配置的規則進行仲裁，這時AS的狀態被修改；另外，預先配置規則這一步非常關鍵，需要預先根據業務種類、相互關係設定這些仲裁規則，由仲裁者去執行。
為了保證業務鏈上的各個AS之間的獨立性，不能出現前面的業務處理依賴於後面的業務處理的中間狀態，或依賴於後面處理結果的影響。如果出現了上面這兩種依賴性，都必須由service broker來處理，進行轉換和屏蔽。因此，每出現一次懸掛/嵌套，或懸掛/中斷，都必然要求service broker充當仲裁角色，從這一點來考慮，該業務鏈上和service broker的每一次交點都是一個仲裁，該鏈上假設有n個AS，則需要經過service broker達n+1次，即可能會產生n個仲裁。顯然必須保證這n個仲裁之間是相互獨立的(即不能互相感知)，同時可以確定，一個仲裁僅僅能夠在屬於自己範圍內的兩個AS之間進行仲裁。根據這一原理，本發明的第一實施例給出了service broker內部結構解決方案。
圖2是根據本發明的第一實施例的業務交互能力管理系統框架圖。首先包含多個AS伺服器10-1，10-2等，然後是service broker邏輯功能20，還有S-CSCF功能實體30。其中service broker邏輯功能20包括多個仲裁者21-1、21-2、21-3等和管理者22。
仲裁者模塊用於在受本次呼叫產生的消息觸發並獲得控制權後，根據預先配置的規則及與管理者模塊22交互得到的本次呼叫相關信息，對本次呼叫產生的消息進行處理，並對本次呼叫產生的交互業務進行仲裁。
而管理者模塊22則充當本地資料庫的角色，用於管理所有呼叫相關信息，同時也充當控制模塊的角色，管理控制權的轉交，通過與所有仲裁者模塊交互以更新本次呼叫相關信息並向仲裁者提供查詢。
其中在一次端對端呼叫過程中，用戶A發起呼叫經過S-CSCF功能30路由到AS伺服器10-1，這時必須先經過service broker功能20，在servicebroker功能20中產生第一個仲裁者21-1來處理這個消息，對於呼入消息不存在多種業務交互，因此直接轉發給AS伺服器10-1，但同時需要上報給管理者22，由管理者22記錄該呼叫的相關信息，並跟蹤記錄該呼叫之後的處理過程。呼叫經由AS伺服器10-1服務後產生消息，引起業務交互，這時觸發發生業務交互的兩個業務間的仲裁者，由仲裁者對消息進行處理，仲裁者首先通知管理者22，獲得該呼叫的相關信息，再根據預先配置的仲裁規則，假定仲裁結果為AS伺服器10-2進行處理，對消息進行修改後轉發給AS伺服器10-2，然後按仲裁結果修改AS伺服器10-1和10-2的狀態，比如被中斷的AS伺服器10-1改為懸掛狀態，中斷AS伺服器10-2則開始運行業務。如此反覆進行，直到呼叫處理結束。
歸納上述工作流程的幾個基本步驟如下首先由本次呼叫產生的消息觸發，對應仲裁者模塊獲得控制權；該仲裁者模塊與管理者模塊交互，得到本次呼叫相關信息；然後，該仲裁者模塊根據預先配置的規則及本次呼叫相關信息，對本次呼叫產生的消息進行處理，並對本次呼叫產生的交互業務進行仲裁；同時，管理者模塊更新本次呼叫相關信息。這個流程就是本發明的業務交互能力管理方法的一個基本實施方式。
本發明的第二實施例在第一實施例的基礎上，給出更詳細的解決方案。在本實施例中，仲裁者對本次呼叫產生的交互業務進行仲裁時，修改本次呼叫產生的消息，並轉發給目的網元，然後通過修改業務的狀態實現交互，之後移交控制權給對應的AS，AS根據業務狀態執行。這裡仲裁者是通過修改業務狀態來通知AS如何動作，以避免衝突或者順利完成交互，從根本上實現AS對業務交互的透明。
業務交互及業務狀態機制的建立需要預先通過業務分析實現，本實施例基於IMS當前各種業務交互情況，給出一種通用的業務分析、模型建立方法，該方法分為業務分類管理、業務特徵分析、仲裁規則生成三步實現。在給仲裁者預先配置規則時，首先對所有業務進行分類管理，使得不同類業務之間不存在交互；再對同一類業務進行特徵分析，獲得任意兩個業務之間的交互關係；根據交互關係配置規則。
如何制定service broker的交互處理規則，是面臨的一個關鍵的問題，這一問題的解決雖然不影響本發明的基本構架，但是本發明第一實施例中基本構架運行的關鍵。本發明第二實施例給出了一般通用的步驟來分析制定交互仲裁規則。
分類管理就是將紛雜的多種多樣的業務進行分類，保證不同類別之間的交互儘量單一化和簡單化；特徵分析就是在已經分好類的某一個類中間，對多個業務可能出現的交互點進行分析，定義和描述，對不同類間，不同群間也進行同樣的分析；生成規則就是依據特徵分析的結果生成最後的規則，表明在什麼條件下，採取什麼仲裁措施。
分類管理就是將關聯性較強的業務歸結為一個類中，沒有關聯性和關聯性單一的歸結為不同類中，一般有如下分類電話業務中呼叫相關類業務或補充業務包括呼叫建立，完成類補充業務CW/CH/MPTY/3part，群類Centrex群或CUG，前轉類補充業務，號碼顯示類，呼叫閉鎖限制類(包括長話權，黑白名單以及各種閉鎖)；電話業務中非呼叫相關類補充業務包括激活去激活類，登記去登記，註冊去註冊；消息類業務包括UC，SMS，MMS，Chat，IM；使能類業務，一般指XDMS/Presence；根據上面的分類，可以保證不同類之間的交互是一種確定的單一化關係，同種類業務的交互則依賴於下面的特徵分析。基於已經完成的分類，可以引入群的概念，將有共同特徵的多個類歸結為一個更抽象的群。
在得到業務分類之後，對於每一類業務需要繼續進行特徵分析，這個過程是最複雜也是最關鍵的過程，service broker的核心就是保證各個AS業務的相對獨立，所有的交互和衝突都只能由service broker自身來完成，對AS/S-CSCF都是透明的。該步驟需要給出業務各種交互關係的定義以及交互處理原則。
本發明第二實施例根據現有業務的各種交互關係歸納如下業務狀態轉移模型業務的狀態包含懸掛、嵌套、中斷、互斥，其中，當兩個交互業務的關係為嵌套且第一個業務嵌套在第二個業務中時，第一個業務處於嵌套狀態並執行，第二個業務處於懸掛狀態並暫停；當兩個交互業務的關係為中斷且第一個業務中斷第二個業務時，第一個業務處於中斷狀態並執行，第二個業務處於懸掛狀態並暫停；當兩個交互業務的關係為互斥且第一個業務優先級高於第二個業務時，執行第一個業務，並終止第二個業務。
可見在本發明第二實施例中，業務交互和衝突被抽象為一種應用業務的前提條件被另外一種應用業務所破壞，基於這種抽象定義上述四種狀態，對於各種業務交互關係及其狀態的進一步描述如下嵌套當一種業務A處理過程中間又觸發了另外一種業務B，則構成嵌套，若且唯若後面的嵌套B處理完畢，才繼續處理本層業務A，嵌套可以允許多層次的嵌套，可以想到，嵌套是構成業務交互的根本；
中斷和嵌套類似，但中斷不允許被再次嵌套或中斷，即一次中斷是排它性和獨佔性的，當中斷完全處理完畢，才回到原來的位置繼續處理，這種情況也可以看成是嵌套的一個最簡特例。一般而言，純事件的觸發，消息類業務都可以定義為中斷；互斥前面分析的結果，和本次的判決具有互斥性，這種情況最為複雜，理論上要根據具體的業務和場景來綜合判斷，為了簡單起見，我們可以採用先得出的結論優先，類似於順序優先，也有採用覆蓋(override)，即最後結果優先的，到底採用哪種方法依賴於不同的實現。典型的如前轉兩次的彩鈴業務；懸掛懸掛是相對而言的，當出現嵌套/中斷時，被嵌套被中斷的業務就處於懸掛狀態，其必和嵌套/中斷相關聯產生。懸掛並不是指一旦被懸掛後必須等待其中的嵌套處理完畢，而是指該懸掛可能被某條消息去懸掛後，躍遷到一個新狀態，再次進入另一種狀態的懸掛。
由此service broker的業務交互可以分解為嵌套/中斷，完全衝突(互斥)，懸掛等幾種類型，上面4種機制是完全對等的，不存在誰優先的問題，任何兩種業務交互必然各自產生上面4種中的一種，否則這兩種業務被認為不存在交互和衝突，此時service broker僅僅起到一個純粹的代理(Proxy)功能，由於Proxy角色已經在相關協議規範中有明確的定義，即主要完成消息轉發等功能。
給出業務狀態轉移機制和仲裁規則配置方案後，整個系統僅需要管理者功能實現後即可完成預期的目的。本實施例中，管理者模塊用於給仲裁者模塊配置規則、記錄呼叫處理信息，並決定控制權在仲裁者模塊及應用伺服器之間轉交，使得AS正常服務，並通過仲裁者有序仲裁後順利完成交互。
這裡提出兩個新的術語相關鏈型集和控制權轉移，它們都是管理者模塊的概念。當每一次消息到達，仲裁者都會向管理者詢問是否具有控制權，並得到當前的相關鏈型集的拓撲視圖，以匹配對應的規則並觸發相應的過程。實際上，這裡的管理者就是一個本地資料庫，保存有當前處理的消息狀態，以及各種視圖數據，如控制權和拓撲等。而管理者模塊需要管理的呼叫相關信息包含呼叫的處理過程、呼叫的業務拓撲結構、呼叫的註冊業務信息、呼叫的處理規則。這些呼叫相關信息必須在過程中動態更新，以提供仲裁者做出正確仲裁。
所謂相關鏈型集，是指將各個AS在整條鏈中流暢地連結起來，保證讓各個AS完全獨立起來，而看不到自己的前後有其它業務在並行觸發。相關鏈型集的拓撲必須有一個管理者，因此service broker必須有一種管理機制，記錄並維護n+1個相關鏈型觸發，也稱為相關鏈型集。
所謂控制權轉移，是指控制權先從S-CSCF轉移到service broker，再轉到AS1，再到service broker，再到AS2，如此循環，這個機制保證避免多個AS同時處理而導致錯誤，一個給定的時刻只有一個AS在處理。
至此，本實施例中的系統已經能夠實現消息觸發仲裁、仲裁與管理交互、仲裁控制業務狀態、AS根據業務狀態執行。此外，本實施例為了提高設計效率和執行效率，還用設計腳本來執行以實現仲裁功能。規則配置的實現即由service broker產生一個運行腳本(script)，仲裁者便於按照該腳本來執行。
用腳本實現規則能夠方便系統的實現和擴展，但腳本的設計將影響執行效率。本實施例通過多維表格查詢和規則匹配的方法實現腳本。仲裁者在獲得控制權後，執行腳本進行仲裁，先根據本次呼叫產生的消息和待仲裁業務，查找二維規則表，根據表項中規則條件與本次呼叫相關信息匹配結果，執行仲裁。
在本發明中，每一個仲裁者都是一個三維的概念，第一個維度是是否具有處理控制權，第二個維度是相關鏈型集的拓撲視圖(包括狀態，前次仲裁結果模型)，收到的消息和方法，第三個維度是被仲裁的業務對象的觸發條件和規則，這3個維度組合起來形成一次仲裁的最終結果。
首先建立一張二維表格，這個表的內容是仲裁規則，而表格由所有消息和業務分別索引，對應某一種業務，當發生某種消息或事件實，查表得到對應表項給出了被觸發的可能性和優先級等信息，供仲裁者參考執行。
另外，引入規則模型(Rule module)用來標識什麼樣的情況下執行什麼樣的操作，這個規則模型包括觸發的條件規則和期望的處理方式，最終以XML等語言的形式表示出來，被service broker的仲裁者所使用，以達到解決業務交互的控制處理。這個規則模型非常類似於3GPP的iFC，即滿足一定的條件，觸發相應的過程。
由此可見，根據規則進行仲裁的方法流程歸納如下當Server broker收到任何消息，首先向管理者詢問控制權，若沒有控制權，則只能緩存該消息或簡單拋棄；若仲裁者獲得控制權，則向管理者詢問拓撲視圖，獲取仲裁對象，各個對象當前處理的消息狀態，前次仲裁結果模型，和收到的消息和方法進行匹配，若不匹配則進入一般的SIP錯誤處理；若匹配則根據收到的消息或方法中攜帶的關鍵信息和特徵，來查詢表格，匹配表項中的觸發條件和規則，若不能匹配，則進入一般SIP錯誤處理，若匹配則獲得最終的處理結果，並依據該結果進行消息處理和控制過程。
最後，還需要指出一點，本發明第二實施例還採用了仲裁者模塊動態產生與消亡機制以節省處理器資源。如前所述，每兩個AS之間需要存在一個仲裁者模塊，然後AS眾多必然使得仲裁者模塊太多而無法高效實現，但注意到每次呼叫時僅僅是所涉及到的AS所對應的幾個仲裁者模塊在起作用，大多數仲裁者模塊不需要執行功能。
因此本發明用動態產生和消亡的方式。由管理者模塊控制仲裁者模塊的產生與消亡，仲裁者模塊在與其相關的消息觸發時產生，在與其相關的交互業務終止後消亡。比如呼叫觸發時，產生對應的仲裁者，而當呼叫所涉及的業務AS中某一種業務終止使得該AS不起作用，這時與該AS相關的所有仲裁功能都失去意義，便可以消亡。這種方式使得系統處理器可以動態調用，大大節約處理器資源，提高系統效率。
本發明第三實施例首先根據具體應用情況給出幾種交互模式的處理流程。定義ServiceBroker針對不同關係需要進行的處理是一個複雜的過程，根據上文分析，歸納為下面幾種懸掛/嵌套這種關係的情況下，仲裁者首先保存有前後兩個UA(假定為A/B)呼叫處理的歷史狀態，當從B收到後續的響應消息時，仲裁者將從管理者資料庫查詢相關控制信息和處理規則，並依據預置的腳本決定處理步驟，當匹配到某條規則時，將該規則定義的處理結果發給A，A根據仲裁者修改後的消息進行處理，繼而完成A的業務邏輯。顯然這時控制權已經由B轉移到A，當A處理完畢後，放棄控制權，此時A已經從一種狀態的懸掛進入到另一種狀態的懸掛。嵌套業務的處理流程如圖3所示。
懸掛/中斷在這種關係下，基本和懸掛/嵌套類似，不同之處在於A不會放棄控制權，而是繼續進行自身的後續處理。
互斥這種關係的處理比較簡單，當仲裁者已經完成仲裁後，相互排斥的業務不會同時出現在相關鏈型集中。這時如果需要繼續選定的業務處理，則被排斥的業務原有邏輯必須被先行終止。互斥業務的處理流程如圖4所示。
本發明的第四實施例是一種典型應用場景下的各個步驟和環節的具體實現方案。最簡單的應用就是通話，比如移動發端呼叫終端時需要觸發呼叫等待(Call Waiting，簡稱「CW」)，呼叫到達時觸發呼叫顯示(Call screening)，而無應答時觸發前轉(forward)、語音郵箱(VoiceMail)等業務，這些業務都是和呼叫相關的呼叫建立業務，因此都歸類為電話業務中呼叫相關類業務或補充業務，相互之間存在交互關係。
對這一類業務進行特徵分析CW就是在傳統意義上的呼叫等待；Call Screening是指在入呼到達時，主叫用戶信息必須先行被記錄並顯示給被叫用戶，被叫據此主叫信息來決定不同的操作，通過按下不同的功能選擇鍵決定是否接受或拒絕該次呼叫，如何選擇不同的功能鍵將通過語音提示來完成；VoiceMail是指語音郵箱功能，在用戶無應答/忙時，可以前轉到語音郵箱。
通過分析，顯然語音郵箱和CW/CallScreening出現了衝突，若該次呼叫到達語音郵箱，則到目標用戶的呼叫建立必然是失敗的，從這個意義上分析，結果要麼是CW/CallScreening呼叫建立成功，要麼是建立失敗而前轉到語音郵箱；其次，CW/CallScreening，這兩個業務都是在Invite時觸發，但由於CallScreening為呼叫建立之前的預處理，因此在時間上應該先處理，當CallScreening處理完畢，則可以繼續正常的被叫流程，此後才觸發被叫的CW流程，因此順序為MT procedure-CallScreening success-CW procedure；另外，語音郵箱是在4XX時觸發的，觸發時機不同於CW/CallScreening。
從上面的分析可以看出，CallScreening和CW形成懸掛/嵌套關係；CallScreening/CW和VoiceMail形成互斥關係。
可以預見，在呼叫過程中將產生以下業務交互情形當被叫的service broker在收到終端Invite時，會觸發CallScreening以及CW，CallScreening具有高優先級，因此觸發CallScreening；當被叫的service broker在收到終端Invite時，會觸發CallScreening以及CW，高優先級CallScreening已經觸發而激活，因此觸發具有次優先級的CW；當被叫的service broker在收到4XX時，企圖觸發前轉語音郵箱，由於語音郵箱和CallScreening/CW是互斥的，因此要想觸發語音郵箱，必須先將CallScreening/CW終結掉，並同時存取4XX事件；最後觸發語音郵箱，完成放音或留言；針對這一情況，接著需要建立仲裁規則，一般而言，觸發業務的順序依賴於觸發點所在呼叫信令的順序，如CW肯定依賴於MT的Invite，因此必然在Invite的時機觸發，而無應答前轉肯定是在4XX時觸發等。但同樣依賴於Invite的多個業務的順序就只能依據具體的業務來指定了，目前沒有一定的規律，依據不同的實現而不同。針對這種情況，有必要引入優先級，同種條件下，要求先觸發的業務具有高優先級，依據不同的優先級，可以很好地解決這個問題。若高優先級已經觸發，也需要在管理者中形成記錄，便於其它仲裁者查詢。由此需要建立如下所示的二維表格描述這些規則。
上表中僅給出涉及到的業務，其它業務的觸發處理優先級順序沒有給出。根據定義完畢的該種表格，可以得出，當Invite到達時，最先觸發CallScreening，然後觸發CW，依此類推。
對於上述表項的內容，還需要給出規則條件，生成腳本如下，其和特徵分析一一對應Rule3a獲得控制權後，收到終端Invite，拓撲圖無，前次仲裁結果無，且被叫籤約數據為CallScreening/CW，則期望的處理為先處理高優級CallScreening；Rule3b獲得控制權後，收到終端Invite，拓撲為MT→CallScreening，且被叫籤約數據為CallScreening/CW，則期望的處理為處理第二優先級CW；Rule3c獲得控制權後，收到4XX消息，拓撲為MT→CallScreening→CW，且被叫籤約了CallScreening/CW/VoiceMail，4XX原因為無應答，則期望的處理為存取4XX消息和事件，反向釋放CW/CallScreening；Rule3d獲得控制權後，如果釋放完畢，拓撲已經變為VoiceMail，4XX事件存在還未處理，且被叫籤約了VoiceMail，則期望的處理為前轉到語音郵箱。
完成規則配置後，先描述一個動態工作流程假設主叫用戶為Jane，被叫B籤約有CW/CallScreening/VoiceMail等業務。考慮一個有代表性的應用場景，Jane發起一個呼叫到B，B無應答後前轉到語音郵箱的情況。為了簡單清晰起見，只考慮B的service broker邏輯的處理。
如圖5所示，處理流程如下第一次收到Invite，則必然匹配到Rule3a，因此CallScreening被激活，CallScreening完成相應操作，記錄主叫Jane的名字，然後將Invite再次發給service broker，並向管理者告知仲裁者1已經建立MT→CallScreening的鏈型拓撲，觸發消息狀態為Invite。
service broker再次收到Invite時，則必然匹配到Rule3b，因此CW被激活，CW完成相應操作，然後將Invite再次發給service broker，這時servicebroker僅僅起到Proxy的角色，將Invite發給用戶B，並向管理者告知仲裁者2建立了CallScreening→CW的鏈型拓撲，觸發消息為Invite。至此總的拓撲為MT→CallScreening→CW。
用戶B返回180，定時器超時後返回無應答4XX，service broker檢測到無應答事件，匹配到Rule3c，轉而存取4XX事件到管理者，並反向釋放CW/CallScreening。注意此時仍然只有仲裁者1和仲裁者2存在。
service broker完成正常的釋放過程，因此向管理者刪除拓撲MT→CallScreening→CW，同時發現還有4XX事件沒有處理，因此匹配到Rule3d，則觸發語音郵箱，並告知管理者仲裁者3已經建立MT→VoiceMail的拓撲，觸發事件為4XX。
熟悉本領域的技術人員可以理解，上述各個實施例給出的具體實現方案是為了幫助理解而具體說明，在實際應用中可以有其它可行的實現方式，這些情況比如在對多種業務進行分類的情況下，可以根據其它法則進行分類，或者抽象為群的概念並引入群管理，將有相同屬性的分類再次歸結為一個更抽象的更高層次的群，使管理者的功能更加具體化和層次化，從而提供一種更為強化的管理者功能；對於兩種業務之間的交互類型的抽象可以更加具體，如對於中斷可以細分為無條件中斷和有條件中斷，對於嵌套也可以細分為觸發新業務的嵌套和觸發新會話的嵌套；在配置規則時，不同群之間Rule module的定義、不同種類業務之間Rulemodule的定義、同種類內不同業務的Rule module的定義，都可以根據實際情況實現；在可能出現一對多業務的情況下(如Forking，Group)，相關鏈型集將可以出現多條子鏈並存的情況，需要增強管理功能，實現多條子鏈的管理關聯性；另外，經過分類管理、特徵分析、生成腳本之後，還可以根據不同的應用場景和本地策略，對最終生成的腳本進行一定的靜態配置，以適應不同運營商的需要；類似上述各種情況，採用其它可行方式實現發明目的，均不影響本發明的實質和範圍。
雖然通過參照本發明的某些優選實施方式，已經對本發明進行了圖示和描述，但本領域的普通技術人員應該明白，可以在形式上和細節上對其作各種改變，而不偏離本發明的精神和範圍。
權利要求
1.一種通信網絡中業務能力交互管理系統，其特徵在於，包含至少一個仲裁者模塊和一個管理者模塊，所述仲裁者模塊用於在受本次呼叫產生的消息觸發並獲得控制權後，根據預先配置的規則和通過與所述管理者模塊交互得到的本次呼叫相關信息，對本次呼叫產生的消息進行處理，並對本次呼叫產生的交互業務進行仲裁；所述管理者模塊用於管理所有呼叫相關信息，管理控制權的轉交，通過與所述仲裁者模塊交互以更新本次呼叫相關信息並向所述仲裁者提供查詢。
2.根據權利要求1所述的通信網絡中業務能力交互管理系統，其特徵在於，所述仲裁者模塊對本次呼叫產生的交互業務進行仲裁時，修改本次呼叫產生的消息，並轉發給目的網元，然後修改所述業務的狀態，並移交控制權給對應的應用伺服器。
3.根據權利要求2所述的通信網絡中業務能力交互管理系統，其特徵在於，所述應用伺服器根據所對應的業務的狀態決定業務的動作，所述業務的狀態包含懸掛、嵌套、中斷、互斥，其中，當兩個交互業務的關係為嵌套且第一個業務嵌套在第二個業務中時，第一個業務處於嵌套狀態並執行，第二個業務處於懸掛狀態並暫停；當兩個交互業務的關係為中斷且第一個業務中斷第二個業務時，第一個業務處於中斷狀態並執行，第二個業務處於懸掛狀態並暫停；當兩個交互業務的關係為互斥且第一個業務優先級高於第二個業務時，執行第一個業務，並終止第二個業務。
4.根據權利要求1所述的通信網絡中業務能力交互管理系統，其特徵在於，所述管理者模塊還用於給所述仲裁者模塊配置規則、記錄呼叫處理信息，並決定控制權在所述仲裁者模塊及應用伺服器之間轉交。
5.根據權利要求4所述的通信網絡中業務能力交互管理系統，其特徵在於，所述管理者模塊還用於管理呼叫相關信息，包含呼叫的處理過程、呼叫的業務拓撲結構、呼叫的註冊業務信息和呼叫的處理規則。
6.根據權利要求1所述的通信網絡中業務能力交互管理系統，其特徵在於，所述仲裁者通過執行預先配置的腳本，對本次呼叫產生的交互業務進行仲裁。
7.根據權利要求6所述的通信網絡中業務能力交互管理系統，其特徵在於，所述仲裁者用於在獲得控制權後，執行腳本進行仲裁，先根據本次呼叫產生的消息和待仲裁業務，查找二維規則表，根據表項中規則條件與本次呼叫相關信息匹配結果，執行仲裁。
8.根據權利要求1至7中任一項所述的通信網絡中業務能力交互管理系統，其特徵在於，所述管理者模塊控制所述仲裁者模塊的產生與消亡，所述仲裁者模塊在與其相關的消息觸發時產生，在與其相關的交互業務終止後消亡。
9.一種通信網絡中業務能力交互管理方法，其特徵在於，包含步驟A由本次呼叫產生的消息觸發，對應仲裁者模塊獲得控制權；B該仲裁者模塊與所述管理者模塊交互，得到本次呼叫相關信息；C該仲裁者模塊根據預先配置的規則及本次呼叫相關信息，對本次呼叫產生的消息進行處理，並對本次呼叫產生的交互業務進行仲裁；D所述管理者模塊更新本次呼叫相關信息。
10.根據權利要求9所述的通信網絡中業務能力交互管理方法，其特徵在於，所述步驟C包含以下子步驟C1所述仲裁者模塊根據預先配置的規則及本次呼叫相關信息進行仲裁；C2所述仲裁者模塊修改本次呼叫產生的消息，並轉發給目的網元；C3所述仲裁者模塊修改所述業務的狀態，並移交控制權給對應的應用伺服器。
11.根據權利要求10所述的通信網絡中業務能力交互管理方法，其特徵在於，所述步驟C3進一步包含以下子步驟所述應用伺服器根據所對應的業務的狀態決定業務的動作，所述業務的狀態包含懸掛、嵌套、中斷、互斥，其中，當兩個交互業務的關係為嵌套且第一個業務嵌套在第二個業務中時，第一個業務處於嵌套狀態並執行，第二個業務處於懸掛狀態並暫停；當兩個交互業務的關係為中斷且第一個業務中斷第二個業務時，第一個業務處於中斷狀態並執行，第二個業務處於懸掛狀態並暫停；當兩個交互業務的關係為互斥且第一個業務優先級高於第二個業務時，執行第一個業務，並終止第二個業務。
12.根據權利要求9所述的通信網絡中業務能力交互管理方法，其特徵在於，還包含步驟所述管理者模塊預先給所述仲裁者模塊配置規則，在呼叫過程中記錄該呼叫的處理信息，並決定控制權在所述仲裁者模塊及應用伺服器之間轉交。
13.根據權利要求9所述的通信網絡中業務能力交互管理方法，其特徵在於，所述管理者模塊所管理的呼叫相關信息包含呼叫的處理過程、呼叫的業務拓撲結構、呼叫的註冊業務信息和呼叫的處理規則。
14.根據權利要求9所述的通信網絡中業務能力交互管理方法，其特徵在於，所述步驟C中所述仲裁者通過執行預先配置的腳本，對本次呼叫產生的交互業務進行仲裁。
15.根據權利要求9所述的通信網絡中業務能力交互管理方法，其特徵在於，所述步驟C中所述仲裁者在獲得控制權後，執行腳本進行仲裁，先根據本次呼叫產生的消息和待仲裁業務，查找二維規則表，根據表項中規則條件與本次呼叫相關信息匹配結果，執行仲裁。
16.根據權利要求9所述的通信網絡中業務能力交互管理方法，其特徵在於，還包含以下步驟所述管理者模塊控制所述仲裁者模塊的產生與消亡，使得所述仲裁者模塊在與其相關的消息觸發時產生、在與其相關的交互業務終止後消亡。
17.根據權利要求9至16中任意一項所述的通信網絡中業務能力交互管理方法，其特徵在於，在預先配置規則時包含以下步驟首先對所有業務進行分類管理，使得不同類業務之間不存在交互；再對同一類業務進行特徵分析，獲得任意兩個業務之間的交互關係；根據交互關係配置規則。
全文摘要
本發明涉及通信領域，公開了一種通信網絡中業務能力交互管理系統及其方法，使得通信網絡中多業務交互和衝突問題得到解決，實現多業務能力交互管理功能。本發明中，通過設置serVice broker邏輯功能，處理AS之間的業務交互；在service broker中設置動態產生和消亡的仲裁者和全局管理者模塊，仲裁者用於對應AS間的業務交互仲裁，管理者用於呼叫相關信息的維護，管理控制權的移交，並提供仲裁者查詢信息，配置仲裁規則；引入業務狀態轉移機制和業務交互模型，包括懸掛、嵌套、中斷和互斥等狀態，和基於這些狀態建立的解決多業務交互的實現機制。
文檔編號H04L29/06GK1905489SQ20061011056
公開日2007年1月31日 申請日期2006年8月8日 優先權日2006年8月8日
發明者葉進洲 申請人:華為技術有限公司