一種新的業(yè)務(wù)沖突檢測(cè)和解決方案

李 旭，胡國(guó)慶

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

0 引言

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

1 業(yè)務(wù)沖突的研究現(xiàn)狀

1.1 業(yè)務(wù)沖突解決方案

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

1.2 業(yè)務(wù)沖突的解決方法

為了有效控制和處理IMS網(wǎng)絡(luò)架構(gòu)下的業(yè)務(wù)沖突檢測(cè)與解決問(wèn)題，3GPP在規(guī)范TS 23.218中，為IMS體系引入了業(yè)務(wù)能力交互管理器(Service Capability Interaction Manager，SCIM)來(lái)專門負(fù)責(zé)協(xié)調(diào)業(yè)務(wù)交互問(wèn)題。之后，3GPP在TR 23.810中又引入了Service Broker功能實(shí)體。總體來(lái)說(shuō)，Service Broker提供了一個(gè)可管理、可控制的手段讓多個(gè)業(yè)務(wù)能夠按照用戶預(yù)想的方式執(zhí)行，根據(jù)用戶業(yè)務(wù)的簽約情況，明確這些業(yè)務(wù)的觸發(fā)順序，并對(duì)存在的業(yè)務(wù)沖突進(jìn)行協(xié)調(diào)。但是3GPP對(duì)SCIM和Service Broker僅提出了概念，并沒(méi)有進(jìn)一步的定義，也沒(méi)有給出具體的功能結(jié)構(gòu)和實(shí)現(xiàn)方式的說(shuō)明。

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

2 一種新的Service Broker的設(shè)計(jì)方案

2.1 Service Broker架構(gòu)圖

Service Broker位于S-CSCF與AS之間，Service Broker與S-CSCF和AS進(jìn)行交互，如圖1所示。通過(guò)對(duì)上述文獻(xiàn)的分析，設(shè)計(jì)了一個(gè)新的 Service Broker架構(gòu)，如圖2所示。

圖1 Service Broker在IMS中的位置

圖2 一種新的Service Broker架構(gòu)

架構(gòu)主要包括:呼叫控制模塊和核心處理模塊2個(gè)模塊。呼叫控制模塊接收來(lái)自S-CSCF和應(yīng)用服務(wù)器的SIP消息，并通過(guò)與核心控制模塊的交互獲得系統(tǒng)內(nèi)部的消息;通過(guò)消息分類功能將消息交給不同的消息處理模塊進(jìn)行處理;當(dāng)收到S-CSCF會(huì)話建立的消息時(shí)，呼叫控制模塊記錄該消息的會(huì)話ID并初始化狀態(tài)機(jī)以跟蹤會(huì)話狀態(tài)，然后將消息發(fā)送到核心處理模塊進(jìn)行沖突檢測(cè)，當(dāng)核心處理模塊指示業(yè)務(wù)觸發(fā)完畢或業(yè)務(wù)沖突導(dǎo)致無(wú)法繼續(xù)執(zhí)行業(yè)務(wù)時(shí)，由會(huì)話管理模塊負(fù)責(zé)尋找默認(rèn)的S-CSCF地址進(jìn)行轉(zhuǎn)發(fā);當(dāng)收到來(lái)自AS的消息時(shí)，將此消息發(fā)送到核心處理模塊進(jìn)行沖突檢測(cè)從而判定是否需要繼續(xù)觸發(fā)業(yè)務(wù)。

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

2.2 業(yè)務(wù)沖突檢測(cè)子模塊

Service Broker分析和研究的重點(diǎn)就是業(yè)務(wù)沖突檢測(cè)子模塊，主要包括:離線業(yè)務(wù)沖突檢測(cè)模塊和在線業(yè)務(wù)沖突檢測(cè)模塊2個(gè)部分。業(yè)務(wù)沖突檢測(cè)子模塊如圖3所示。

圖3 業(yè)務(wù)沖突檢測(cè)子模塊

離線沖突管理模塊負(fù)責(zé)離線業(yè)務(wù)沖突的檢測(cè)和解決，離線沖突檢測(cè)模塊由離線規(guī)則庫(kù)和離線業(yè)務(wù)沖突檢測(cè)算法組成。借鑒傳統(tǒng)的二維表業(yè)務(wù)沖突檢測(cè)方法，在這里把傳統(tǒng)的靜態(tài)二維表擴(kuò)展成動(dòng)態(tài)二維表。

動(dòng)態(tài)二維表沖突檢測(cè)算法的原理:在靜態(tài)二維表的基礎(chǔ)上增加了發(fā)現(xiàn)沖突時(shí)的執(zhí)行策略，即在發(fā)現(xiàn)沖突時(shí)，根據(jù)預(yù)先設(shè)定的方案解決該業(yè)務(wù)沖突。如果業(yè)務(wù)之間沒(méi)有沖突，則依次進(jìn)行觸發(fā)。處理流程如下:

①當(dāng)系統(tǒng)啟動(dòng)時(shí)，將業(yè)務(wù)二維表從數(shù)據(jù)庫(kù)中調(diào)入到內(nèi)存中，完成數(shù)據(jù)的初始化存儲(chǔ);

②根據(jù)用戶文檔，核心處理模塊得知會(huì)話將要觸發(fā)的業(yè)務(wù)，由動(dòng)態(tài)二維分析表來(lái)檢查這些業(yè)務(wù)之間是否存在業(yè)務(wù)沖突;

③如果存在沖突，則根據(jù)預(yù)先制定的解決方案來(lái)解決該業(yè)務(wù)沖突;

④如果沒(méi)檢測(cè)到業(yè)務(wù)沖突則將用戶請(qǐng)求消息交給在線業(yè)務(wù)沖突管理器進(jìn)一步處理。

在線沖突管理模塊由在線規(guī)則庫(kù)業(yè)務(wù)沖突分類模塊和循環(huán)沖突檢測(cè)算法組成。根據(jù)在線規(guī)則庫(kù)判斷該業(yè)務(wù)是否存在沖突;然后通過(guò)業(yè)務(wù)沖突分類模塊判斷是否為循環(huán)業(yè)務(wù)沖突;如果不是，就把該業(yè)務(wù)沖突信息返回給離線沖突檢測(cè)模塊，擴(kuò)展動(dòng)態(tài)二維表;如果是循環(huán)沖突，就采用循環(huán)檢測(cè)算法進(jìn)行業(yè)務(wù)沖突檢測(cè)。

循環(huán)沖突檢測(cè)算法的原理:在系統(tǒng)中保存2個(gè)字段(Source-List和Destination-List)的定義，Source-List保存每次轉(zhuǎn)發(fā)時(shí)的源地址列表，每次轉(zhuǎn)發(fā)時(shí)把源地址和最終目的地址添加到Source-List末尾。Destination-List保存每次轉(zhuǎn)發(fā)時(shí)的下一跳地址列表，每次轉(zhuǎn)發(fā)時(shí)添加下一跳地址和最終目的地址到列表。若

即Destination-List列表中的地址集合是Source-List列表中的子集，則認(rèn)為出現(xiàn)循環(huán)，即檢測(cè)到?jīng)_突。然后對(duì)其該消息，并釋放會(huì)話，結(jié)束本次沖突檢測(cè)。

3 實(shí)驗(yàn)結(jié)果

為了驗(yàn)證該Service Broker架構(gòu)檢測(cè)解決業(yè)務(wù)沖突的有效性，按照?qǐng)D4所示驗(yàn)證平臺(tái)進(jìn)行了試驗(yàn)驗(yàn)證，將 X-Lite軟終端(A、B、C)、CSCF服務(wù)器、HSS、SIP服務(wù)器和 Service Broker連接到交換機(jī)。在SIP服務(wù)器上部署了2個(gè)業(yè)務(wù):呼叫前轉(zhuǎn)業(yè)務(wù)和呼叫代答業(yè)務(wù)。

圖4 Service Broker驗(yàn)證平臺(tái)

情景1:設(shè)用戶B同時(shí)訂閱了呼叫代答業(yè)務(wù)和呼叫前轉(zhuǎn)業(yè)務(wù)，用戶B注冊(cè)為呼叫前轉(zhuǎn)用戶C。

用戶A呼叫用戶B，首先在離線業(yè)務(wù)沖突檢測(cè)模塊中調(diào)用動(dòng)態(tài)二維表算法，檢測(cè)到呼叫代答和呼叫前轉(zhuǎn)業(yè)務(wù)之間存在沖突。根據(jù)預(yù)先制定的策略執(zhí)行呼叫前轉(zhuǎn)業(yè)務(wù)。

情景2:設(shè)用戶A、B、C均訂閱了呼叫前轉(zhuǎn)業(yè)務(wù)，其中用戶A注冊(cè)為呼叫前轉(zhuǎn)用戶B，用戶B注冊(cè)為呼叫前轉(zhuǎn)用戶C，用戶C注冊(cè)為呼叫前轉(zhuǎn)用戶A。這是一個(gè)典型的活鎖類業(yè)務(wù)沖突。

當(dāng)用戶A、B、C中的任何一個(gè)用戶撥打其中的另外一個(gè)用戶時(shí)，首先在離線業(yè)務(wù)沖突檢測(cè)模塊中調(diào)用動(dòng)態(tài)二維表算法，沒(méi)有檢測(cè)到業(yè)務(wù)沖突，然后將業(yè)務(wù)請(qǐng)求消息轉(zhuǎn)交給在線沖突檢測(cè)模塊;在線沖突檢測(cè)模塊調(diào)用循環(huán)沖突檢測(cè)算法，求出Source-List={A，B，C}，Destination-List={B，C，A}，因?yàn)?/p>

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

4 結(jié)束語(yǔ)

依據(jù)3GPP針對(duì)SCIM和Service Broker提出的功能需求，參考現(xiàn)有的業(yè)務(wù)沖突檢測(cè)和解決方法，提出了一個(gè)Service Broker架構(gòu)。該架構(gòu)的業(yè)務(wù)沖突檢測(cè)子模塊對(duì)業(yè)務(wù)沖突采用二級(jí)檢測(cè)，先對(duì)離線業(yè)務(wù)沖突進(jìn)行檢測(cè)，然后對(duì)在線業(yè)務(wù)沖突進(jìn)行檢測(cè)和解決。通過(guò)動(dòng)態(tài)二維分析表方法進(jìn)行離線業(yè)務(wù)沖突檢測(cè)和解決;通過(guò)循環(huán)檢測(cè)算法進(jìn)行在線業(yè)務(wù)沖突的檢測(cè)和處理。并通過(guò)離線規(guī)則庫(kù)和在線規(guī)則庫(kù)之間的交互對(duì)動(dòng)態(tài)二維表進(jìn)行擴(kuò)展，以解決新的業(yè)務(wù)沖突。該架構(gòu)能夠提高業(yè)務(wù)沖突檢測(cè)的效率和成功率。 ■

［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］魏 薇，楊放春.基于免疫學(xué)的多層防護(hù)業(yè)務(wù)沖突管理系統(tǒng)研究［J］.高技術(shù)通訊，2007，17(4):362 －367.

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