一種新的業務沖突檢測和解決方案

李 旭，胡國慶

(1.中國電子科技集團公司第五十四研究所，河北石家莊 050081;2.總參信息化部駐石家莊地區軍事代表室，河北石家莊 050081)

0 引言

隨著通信技術和網絡技術的快速發展，能夠融合多種異構網絡、提供多媒體綜合業務和開放網絡資源能力的下一代網絡體系結構逐漸形成。IP多媒體子系統(IP Multimedia Subsystem，IMS)是下一代網絡的核心技術，IMS采用了控制和業務相分離的水平式分層架構。IMS既支持傳統電信網、智能網的業務，又為新業務的開發和部署提供了開放的平臺，從而進一步簡化了第三方業務的開發和部署。實驗證明，業務之間存在著特征交互，可能會延遲業務部署，從而給業務的快速提供帶來不便。隨著新業務的大量部署，在下一代網絡中業務之間的特征交互問題將會更加突出。

1 業務沖突的研究現狀

1.1 業務沖突解決方案

根據著眼點的不同，業務沖突的研究內容可以從2個角度進行歸納:①根據業務的生命周期將其分為離線(Off-Line)研究和在線(On-Line)研究2類;②根據業務沖突的研究目的將其分為避免(Avoidance)、檢測(Detection)和解決(Resolution)3類。這2個方面的研究內容互為重疊，共同組成了業務沖突問題的整體解決方案。

1.2 業務沖突的解決方法

為了有效控制和處理IMS網絡架構下的業務沖突檢測與解決問題，3GPP在規范TS 23.218中，為IMS體系引入了業務能力交互管理器(Service Capability Interaction Manager，SCIM)來專門負責協調業務交互問題。之后，3GPP在TR 23.810中又引入了Service Broker功能實體。總體來說，Service Broker提供了一個可管理、可控制的手段讓多個業務能夠按照用戶預想的方式執行，根據用戶業務的簽約情況，明確這些業務的觸發順序，并對存在的業務沖突進行協調。但是3GPP對SCIM和Service Broker僅提出了概念，并沒有進一步的定義，也沒有給出具體的功能結構和實現方式的說明。

文獻［3］提出了一種解決離線業務沖突的方法，定義了業務的描述方式以及檢測業務沖突的準則。通過比較2個業務的描述信息進行沖突檢測，一旦發現沖突，就采用事先定義的解決算法選擇一個業務來執行。這種方法主要局限于離線業務沖突的檢測和解決，不能處理在線的業務沖突。文獻［4－7］介紹了 Lucent Service Broker的設計方案。Lucent Service Broker的消息處理邏輯是由Steplets控制的，Steplets是可以動態加載的程序片段。Lucent Service Broker是一種層次化架構:最核心的部分是Steplets集合;在此之上由SIP層和HTTP層調用Steplets協調業務關系。文獻［8，9］介紹了一種基于免疫學的多層防護業務沖突檢測規則和管理系統，將免疫識別過程中的一些重要原理(抗原識別、協同刺激和克隆選擇等)借鑒到業務沖突的在線檢測和解決中，對業務沖突具有較好的適應性和擴展性。然而由于專家經驗知識有限和業務沖突問題本身的復雜性，這種方法往往存在較大的漏報和誤報。

2 一種新的Service Broker的設計方案

2.1 Service Broker架構圖

Service Broker位于S-CSCF與AS之間，Service Broker與S-CSCF和AS進行交互，如圖1所示。通過對上述文獻的分析，設計了一個新的 Service Broker架構，如圖2所示。

圖1 Service Broker在IMS中的位置

圖2 一種新的Service Broker架構

架構主要包括:呼叫控制模塊和核心處理模塊2個模塊。呼叫控制模塊接收來自S-CSCF和應用服務器的SIP消息，并通過與核心控制模塊的交互獲得系統內部的消息;通過消息分類功能將消息交給不同的消息處理模塊進行處理;當收到S-CSCF會話建立的消息時，呼叫控制模塊記錄該消息的會話ID并初始化狀態機以跟蹤會話狀態，然后將消息發送到核心處理模塊進行沖突檢測，當核心處理模塊指示業務觸發完畢或業務沖突導致無法繼續執行業務時，由會話管理模塊負責尋找默認的S-CSCF地址進行轉發;當收到來自AS的消息時，將此消息發送到核心處理模塊進行沖突檢測從而判定是否需要繼續觸發業務。

核心處理模塊通過與呼叫控制模塊交互，并利用沖突檢測模塊提供的接口，控制完成IMS系統中用戶訂閱的一組業務的業務觸發及沖突檢測和處理。接收會話控制模塊的調用，從傳入的消息中獲得本次的會話 ID，讀取對話的觸發階段 Trigger-Stage和已觸發業務列表Service-List，據此將消息分發到不同的模塊進行處理;首先調用業務觸發接口，然后調用沖突檢測接口，如果有沖突則繼續調用業務觸發接口;通過業務觸發接口查詢用戶的自定義規則和初始過濾準則(initial Filter Criteria，iFC)文件查詢下一個需要觸發的業務編號返回給調用接口;業務沖突檢測模塊則通過離線業務沖突和在線業務沖突管理子模塊對業務沖突進行檢測和解決。

2.2 業務沖突檢測子模塊

Service Broker分析和研究的重點就是業務沖突檢測子模塊，主要包括:離線業務沖突檢測模塊和在線業務沖突檢測模塊2個部分。業務沖突檢測子模塊如圖3所示。

圖3 業務沖突檢測子模塊

離線沖突管理模塊負責離線業務沖突的檢測和解決，離線沖突檢測模塊由離線規則庫和離線業務沖突檢測算法組成。借鑒傳統的二維表業務沖突檢測方法，在這里把傳統的靜態二維表擴展成動態二維表。

動態二維表沖突檢測算法的原理:在靜態二維表的基礎上增加了發現沖突時的執行策略，即在發現沖突時，根據預先設定的方案解決該業務沖突。如果業務之間沒有沖突，則依次進行觸發。處理流程如下:

①當系統啟動時，將業務二維表從數據庫中調入到內存中，完成數據的初始化存儲;

②根據用戶文檔，核心處理模塊得知會話將要觸發的業務，由動態二維分析表來檢查這些業務之間是否存在業務沖突;

③如果存在沖突，則根據預先制定的解決方案來解決該業務沖突;

④如果沒檢測到業務沖突則將用戶請求消息交給在線業務沖突管理器進一步處理。

在線沖突管理模塊由在線規則庫業務沖突分類模塊和循環沖突檢測算法組成。根據在線規則庫判斷該業務是否存在沖突;然后通過業務沖突分類模塊判斷是否為循環業務沖突;如果不是，就把該業務沖突信息返回給離線沖突檢測模塊，擴展動態二維表;如果是循環沖突，就采用循環檢測算法進行業務沖突檢測。

循環沖突檢測算法的原理:在系統中保存2個字段(Source-List和Destination-List)的定義，Source-List保存每次轉發時的源地址列表，每次轉發時把源地址和最終目的地址添加到Source-List末尾。Destination-List保存每次轉發時的下一跳地址列表，每次轉發時添加下一跳地址和最終目的地址到列表。若

即Destination-List列表中的地址集合是Source-List列表中的子集，則認為出現循環，即檢測到沖突。然后對其該消息，并釋放會話，結束本次沖突檢測。

3 實驗結果

為了驗證該Service Broker架構檢測解決業務沖突的有效性，按照圖4所示驗證平臺進行了試驗驗證，將 X-Lite軟終端(A、B、C)、CSCF服務器、HSS、SIP服務器和 Service Broker連接到交換機。在SIP服務器上部署了2個業務:呼叫前轉業務和呼叫代答業務。

圖4 Service Broker驗證平臺

情景1:設用戶B同時訂閱了呼叫代答業務和呼叫前轉業務，用戶B注冊為呼叫前轉用戶C。

用戶A呼叫用戶B，首先在離線業務沖突檢測模塊中調用動態二維表算法，檢測到呼叫代答和呼叫前轉業務之間存在沖突。根據預先制定的策略執行呼叫前轉業務。

情景2:設用戶A、B、C均訂閱了呼叫前轉業務，其中用戶A注冊為呼叫前轉用戶B，用戶B注冊為呼叫前轉用戶C，用戶C注冊為呼叫前轉用戶A。這是一個典型的活鎖類業務沖突。

當用戶A、B、C中的任何一個用戶撥打其中的另外一個用戶時，首先在離線業務沖突檢測模塊中調用動態二維表算法，沒有檢測到業務沖突，然后將業務請求消息轉交給在線沖突檢測模塊;在線沖突檢測模塊調用循環沖突檢測算法，求出Source-List={A，B，C}，Destination-List={B，C，A}，因為

即Destination-List是Source-List的子集，由此判斷出本次呼叫存在活鎖類業務沖突，放棄本次會話。

4 結束語

依據3GPP針對SCIM和Service Broker提出的功能需求，參考現有的業務沖突檢測和解決方法，提出了一個Service Broker架構。該架構的業務沖突檢測子模塊對業務沖突采用二級檢測，先對離線業務沖突進行檢測，然后對在線業務沖突進行檢測和解決。通過動態二維分析表方法進行離線業務沖突檢測和解決;通過循環檢測算法進行在線業務沖突的檢測和處理。并通過離線規則庫和在線規則庫之間的交互對動態二維表進行擴展，以解決新的業務沖突。該架構能夠提高業務沖突檢測的效率和成功率。 ■

［1］3GPP TS 23.218.IP Multimedia(IM)Session Handling;IM Call Model［S］.

［2］3GPP TR 23.810.Study on Architecture Impacts of Service Brokering［S］.

［3］KOLBERG M， MAGILL E H. Managing Feature Interactions between Distributed SIP Call Control Services［J］.Computer Networks，2007，51(2):536 －557.

［4］ANUPAM V，HULL R B，KANWAL S S，et al.An Introduction to Lucent’s Service Enhancement Layer［J］.Bell Labs Technical Journal，2006，10(4):179 －196.

［5］DEVITO N M，EMERY R T，KOCAN K F，et al.Functionality and Structure of the Service Broker in Advanced Service Architectures［J］.Bell Labs Technical Journal，2005，10(1):17 －30.

［6］KOCAN KF，ROOMEWD，ANUPAMV.Service Capability Interaction Management in IMS Using the Lucent Service Broker Product［J］.Bell Labs Technical Journal，2006，10(4)，217 －232.

［7］KOCAN K F，ROOME W D，ANUPAM V.A Novel Software Approach for Service Brokering in Advanced Service Architectures ［J］.Bell Labs Technical Journal，2006，11(1):5 －20.

［8］魏 薇，楊放春.基于免疫學的多層防護業務沖突管理系統研究［J］.高技術通訊，2007，17(4):362 －367.

［9］魏 薇，楊放春.基于免疫學的多層防護業務沖突檢測方法［J］.電子與信息學報，2007，29(10):2455－2459.