曹 毅，李 旭

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

0 引言

下一代網(wǎng)絡(luò)采用了控制和業(yè)務(wù)相分離的水平式分層架構(gòu)，從而進(jìn)一步簡(jiǎn)化了第三方業(yè)務(wù)的開(kāi)發(fā)和部署。隨著新業(yè)務(wù)的大量部署，在下一代網(wǎng)絡(luò)中業(yè)務(wù)之間的特征交互問(wèn)題將會(huì)更加突出。

大多數(shù)業(yè)務(wù)沖突問(wèn)題都與業(yè)務(wù)觸發(fā)機(jī)制相關(guān)。首先，IMS采用基于iFC逐次匹配觸發(fā)的機(jī)制實(shí)現(xiàn)了業(yè)務(wù)與呼叫控制的分離。服務(wù)呼叫會(huì)話控制功能(Serving-Call/Session Control Function，S-CSCF)按照優(yōu)先級(jí)依次匹配每一條iFC，匹配成功后觸發(fā)相應(yīng)的應(yīng)用服務(wù)器(Application Server，AS)來(lái)執(zhí)行業(yè)務(wù)。S-CSCF接著匹配下一優(yōu)先級(jí)的iFC，觸發(fā)相關(guān)的AS，依次進(jìn)行直到匹配完所有的iFC。這種觸發(fā)機(jī)制在初始請(qǐng)求到來(lái)時(shí)，按靜態(tài)配置好的順序觸發(fā)相關(guān)AS。再有，應(yīng)用服務(wù)器都是相互孤立的，彼此并不知道對(duì)方的存在，AS之間無(wú)法進(jìn)行交互，不能根據(jù)應(yīng)用服務(wù)器的交互結(jié)果決定相應(yīng)的回應(yīng)。因此，IMS中基于iFC的業(yè)務(wù)觸發(fā)機(jī)制是業(yè)務(wù)沖突產(chǎn)生的根源。

1 業(yè)務(wù)交互問(wèn)題現(xiàn)狀

1.1 業(yè)務(wù)交互的分類(lèi)

業(yè)務(wù)交互可以分為2類(lèi):① 特征沖突，即違背用戶意愿的業(yè)務(wù)交互;②特征協(xié)作，即用戶期望的特征交互稱(chēng)為特征協(xié)作。特征是指那些業(yè)務(wù)中不能獨(dú)立運(yùn)行但功能相對(duì)完整的功能模塊，或者稱(chēng)為業(yè)務(wù)能力。

1.2 Service Broker

為了有效控制和處理IMS網(wǎng)絡(luò)架構(gòu)下的業(yè)務(wù)沖突檢測(cè)與解決問(wèn)題，3GPP在TR 23.810中引入了Service Broker功能實(shí)體?？傮w來(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)。從本質(zhì)上說(shuō)，服務(wù)呼叫/會(huì)話控制功能中基于iFC的業(yè)務(wù)觸發(fā)流程就是Service Broker的一種靜態(tài)工作形式。

3GPP并沒(méi)有對(duì)Service Broker進(jìn)一步定義，也沒(méi)有給出具體的功能結(jié)構(gòu)和實(shí)現(xiàn)方式的說(shuō)明。但在設(shè)計(jì)Service Broker時(shí)需注意以下問(wèn)題:①盡可能減少由于引入Service Broker而對(duì)IMS核心網(wǎng)造成的影響;②Service Broker采用靈活的架構(gòu)以便處理新業(yè)務(wù)之間的交互問(wèn)題;③支持不同接入方式的業(yè)務(wù)之間的交互;④ 支持由用戶配置、控制業(yè)務(wù)交互方式。

2 Service Broker架構(gòu)設(shè)計(jì)

為了解決IMS中的業(yè)務(wù)交互問(wèn)題，提出了一種新的Service Broker模型，如圖1所示。主要由服務(wù)請(qǐng)求接口、數(shù)據(jù)處理模塊、業(yè)務(wù)觸發(fā)模塊和兼容類(lèi)交互管理模塊組成。

服務(wù)請(qǐng)求接口采用 SIP協(xié)議的ISC接口，負(fù)責(zé)在S-CSCF和AS之間消息的傳遞。在新的業(yè)務(wù)提供架構(gòu)下，S-CSCF與 AS之間的交互由Service Broker進(jìn)行管理，同時(shí)對(duì)于二者又都是透明的。因此，沿用傳統(tǒng)IMS體系中的ISC接口，分別為AS和S-CSCF提供相應(yīng)的數(shù)據(jù)傳輸功能。S-CSCF將Service Broker當(dāng)作是一個(gè)支持ISC的 AS，將請(qǐng)求消息轉(zhuǎn)發(fā)給 Service Broker，由Service Broker決定進(jìn)一步調(diào)用哪個(gè)AS或者其他操作。對(duì)于AS相應(yīng)業(yè)務(wù)請(qǐng)求后的應(yīng)答和產(chǎn)生的請(qǐng)求，同樣由業(yè)務(wù)管理模塊處理(沖突檢測(cè)和避免)，然后決定下一步動(dòng)作。

數(shù)據(jù)處理模塊提供Service Broker與HSS之間的接口，采用基于Diameter協(xié)議的Sh接口，從HSS下載用戶簽約的業(yè)務(wù)數(shù)據(jù)，包括iFC，然后處理數(shù)據(jù)并將處理后的數(shù)據(jù)轉(zhuǎn)交給業(yè)務(wù)觸發(fā)模塊和兼容類(lèi)交互管理模塊。兼容類(lèi)交互管理模塊負(fù)責(zé)把從HSS下載的用戶簽約的業(yè)務(wù)數(shù)據(jù)，劃分為不同的兼容類(lèi)，并確定兼容類(lèi)之間的邏輯交互關(guān)系。

圖1 Service Broker系統(tǒng)架構(gòu)

3 Service Broker系統(tǒng)原理

3.1 Service Broker在網(wǎng)絡(luò)架構(gòu)中的地位

圖2 基于兼容類(lèi)的業(yè)務(wù)觸發(fā)

為了有效控制和處理IMS網(wǎng)絡(luò)架構(gòu)下的業(yè)務(wù)沖突檢測(cè)與解決問(wèn)題，3GPP在TR 23.810中引入了Service Broker功能實(shí)體?？傮w來(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)。從本質(zhì)上說(shuō)，服務(wù)呼叫/會(huì)話控制功能中基于iFC的業(yè)務(wù)觸發(fā)流程就是Service Broker的一種靜態(tài)工作形式。

3GPP并沒(méi)有對(duì)Service Broker進(jìn)一步定義，也沒(méi)有給出具體的功能結(jié)構(gòu)和實(shí)現(xiàn)方式的說(shuō)明。設(shè)計(jì)Service Broker時(shí)需注意以下問(wèn)題:①盡可能減少由于引入Service Broker而對(duì)IMS核心網(wǎng)造成的影響;②Service Broker采用靈活的架構(gòu)以便處理新業(yè)務(wù)之間的交互問(wèn)題;③支持不同接入方式的業(yè)務(wù)之間的交互;④支持由用戶配置、控制業(yè)務(wù)交互方式。

3.2 算法設(shè)計(jì)

為了實(shí)現(xiàn)Service Broker的業(yè)務(wù)交互管理功能，這里引入了兼容類(lèi)的概念。在一個(gè)會(huì)話中觸發(fā)的多個(gè)業(yè)務(wù)分別屬于3個(gè)兼容類(lèi):類(lèi)A、類(lèi)B和類(lèi)C，則兼容類(lèi)之間存在以下關(guān)系:

①如果2個(gè)類(lèi)相互兼容，則其中的業(yè)務(wù)不會(huì)沖突，否則會(huì)產(chǎn)生業(yè)務(wù)沖突;

②如果類(lèi)A和類(lèi)C兼容，類(lèi)A和類(lèi)B不兼容，則類(lèi)C和類(lèi)B不兼容。

兼容類(lèi)信息存儲(chǔ)在HSS中的iFC信息中，可以加載到Service Broker中，指示Service Broker在上一條iFC被成功調(diào)用后，如果本條iFC匹配成功，是否可以觸發(fā)。不同兼容類(lèi)之間的交互準(zhǔn)則也被提前配置到Service Broker上。兼容類(lèi)的交互準(zhǔn)則以XML文檔的形式存儲(chǔ)在Service Broker中。例如:在用戶文檔中包含4條iFC，份屬于兼容類(lèi)A，B，C。其中:iFC1，iFC2∈A;iFC3∈B;iFC4∈C。

基于兼容類(lèi)的業(yè)務(wù)觸發(fā)如圖2所示。

圖2中兼容類(lèi)A和類(lèi)B不兼容。兼容類(lèi)A和類(lèi)C兼容。本例中類(lèi)A中的iFC1或iFC2觸發(fā)后，類(lèi)B中的iFC將不被觸發(fā)。

3.3 系統(tǒng)流程分析

業(yè)務(wù)觸發(fā)模塊在業(yè)務(wù)觸發(fā)的過(guò)程中，結(jié)合初始過(guò)濾準(zhǔn)則的優(yōu)先級(jí)和兼容類(lèi)完成業(yè)務(wù)觸發(fā)?；诩嫒蓊?lèi)的業(yè)務(wù)觸發(fā)流程如圖3所示。

圖3 基于兼容類(lèi)的業(yè)務(wù)觸發(fā)流程

基于兼容類(lèi)的業(yè)務(wù)觸發(fā)流程如下:① Service Broker收到業(yè)務(wù)觸發(fā)消息后，選取最高優(yōu)先級(jí)iFC進(jìn)行評(píng)估;②如果匹配成功，進(jìn)行業(yè)務(wù)觸發(fā)，否則轉(zhuǎn)步驟⑥;③ 業(yè)務(wù)觸發(fā)完成后，判斷該iFC是不是最后一條;如果是最后一條，結(jié)束觸發(fā);如果不是，轉(zhuǎn)步驟④;④ 在剩余iFC中選取最高優(yōu)先級(jí)的iFC，進(jìn)行兼容性判斷;⑤如果不兼容，轉(zhuǎn)步驟③;否則轉(zhuǎn)步驟②;⑥ 判斷iFC是不是最后一條iFC，如果不是，轉(zhuǎn)步驟①;否則，結(jié)束業(yè)務(wù)觸發(fā)。

4 實(shí)驗(yàn)驗(yàn)證

為了驗(yàn)證該Service Broker架構(gòu)檢測(cè)解決業(yè)務(wù)沖突的有效性，按照?qǐng)D4進(jìn)行了試驗(yàn)驗(yàn)證，將X-Lite軟終端(UE1，UE2)、SCSCF、HSS、AS和Service Broker連接到交換機(jī)上。在AS上部署了2個(gè)業(yè)務(wù):免費(fèi)電話業(yè)務(wù)和呼出禁止業(yè)務(wù)。

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

考慮一個(gè)用戶文檔，其中包含2條初始過(guò)濾準(zhǔn)則分別對(duì)應(yīng)免費(fèi)電話業(yè)務(wù)和呼出禁止業(yè)務(wù)。如果該用戶選擇訂閱免費(fèi)呼叫業(yè)務(wù)，這時(shí)第1條過(guò)濾準(zhǔn)則匹配成功，然后INVITE消息被路由到相應(yīng)的AS上，AS把免費(fèi)呼叫的號(hào)碼翻譯成合適的地區(qū)號(hào)，根據(jù)現(xiàn)有的IMS業(yè)務(wù)觸發(fā)流程，當(dāng)AS產(chǎn)生的INVITE消息返回時(shí)，第2條過(guò)濾準(zhǔn)則將被評(píng)估且匹配成功。如果該用戶不允許向目的地發(fā)出呼叫，免費(fèi)呼叫業(yè)務(wù)將被禁止，違背了用戶意愿。

在基于兼容類(lèi)的業(yè)務(wù)提供環(huán)境下，2條iFC分別屬于不同的兼容類(lèi)，并且2個(gè)類(lèi)不兼容，根據(jù)iFC的優(yōu)先級(jí)，免費(fèi)電話業(yè)務(wù)將被觸發(fā)，第2條iFC將不被評(píng)估，呼出禁止業(yè)務(wù)不被觸發(fā)。

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

提出的基于兼容類(lèi)的Service Broker系統(tǒng)能夠和現(xiàn)有的基于iFC的業(yè)務(wù)觸發(fā)機(jī)制結(jié)合，有效地解決NGN中的業(yè)務(wù)交互問(wèn)題。該Service Broker系統(tǒng)對(duì)現(xiàn)有的NGN網(wǎng)絡(luò)架構(gòu)影響很小，不需要現(xiàn)有的NGN網(wǎng)絡(luò)架構(gòu)進(jìn)行改變，因此便于部署。 ■

［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］3GPP TS 29.198 － 16.Service Broker Service Capability Feature(SCF)［S］.

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

［5］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.

［6］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.

［7］KOCAN K F，ROOME W.D，ANUPAM V.Service Capability Interaction Management in IMS Using the Lucent Service Broker Product［J］.Bell Labs Technical Journal，2006，10(4)，217 －232.

［8］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.