摘要 針對IMS中業務交互管理問題，本文首先介紹和分析了IMS中現有基於過濾規則的業務觸發機制和存在問題，然後針對3GPP標準中新增的SCIM實體，介紹了相關研究現狀和改進方式，最後分析了現有業務交互管理中存在的問題並提出下一步發展方向。
1、引言
IMS（IP多媒體子系統）是第三代移動網絡的核心網技術。它採用IP傳送技術，同時業務層面在兼容目前已有的業務的同時開放了網絡能力接口，爲業務開發商提供了方便、快捷、經濟地提供業務的途徑。這種開放的全IP的架構使得IMS上的業務可以變得豐富多彩，同時也使業務交互問題變得更爲明顯。
業務交互指的兩個或者多個業務在同時執行的過程中相互影響甚至干擾。根據是否違反用戶期望，業務交互分爲業務協作和業務衝突。業務協作是用戶期望的交互行爲，例如將已有的多個業務或業務能力組合成爲一個新業務；業務衝突是用戶未預期的交互行爲。一個業務衝突的例子是“主叫呼出限制（OCS）”和“被叫呼叫轉移（CFU）”：假設用戶A訂購了OCS業務並限制撥打用戶B，而用戶C訂購了CFU業務並設置前轉地址爲B，當用戶A呼叫用戶C時，該呼叫被CFU業務轉移到用戶B，而用戶B在OCS限制的範圍內，這便產生了違背用戶意願的業務衝突，原本用戶A與B的通話應該被OCS業務限制的，而現在用戶A卻與B進行通話。
業務協作有助於方便、快速、經濟地提供新業務，可以提高用戶體驗，而業務衝突則會影響用戶體驗，甚至影響系統穩定性和安全性。由於業務交互問題的重要性，業界給予了長期的關注。在IMS發展部署過程中，這也是亟待解決的重要問題。3GPP定義了SCIM/Service Broker（業務能力交互管理器/業務代理）實體來處理IMS中的業務交互問題。目前3GPP對該問題正處於研究之中，相關標準尚未成熟。
2、IMS中的觸發機制和存在的問題
業務交互問題的已有研究和統計分類表明，多數業務交互問題都與業務觸發機制相關。例如，共享觸發類的業務衝突就是在同一事件點觸發了多個業務從而產生衝突。在什麼情況下觸發業務，選擇哪個業務來執行，就是觸發機制應當解決的問題，如果不能恰當地解決此問題就會導致衝突。
3GPP的標準中，業務觸發的方式是S-CSCF（服務呼叫會話控制功能）按照iFC（初始過濾準則）的優先級依次匹配每一條iFC，匹配成功後觸發相應的應用服務器（AS）來執行業務。AS可以對請求消息作一定的處理後再返回給S-CSCF，S-CSCF接着匹配下一優先級的iFC，觸發相關的AS，依次進行直到匹配完所有的iFC。iFC中規定了多個觸發點（SPT），在匹配過程中S-CSCF檢查當前會話的情況是否滿足觸發點的要求。目前規定有5類觸發點，分別是Request URI、SIP方法、SIP Header、會話描述、會話情形（Originating、Terminating Terminating_Unregistered）。
爲了使S-CSCF按正確的順序處理不同的FC，每個FC都必須分配一個優先級，並且在提供給用戶的FC中，不應該有一個優先級對應一個以上的FC。如果S-CSCF不能聯繫到AS，那麼S-CSCF應該爲這個觸發使用默認的處理方式。默認處理可以是：如果在列表中匹配了一個低優先級觸發項，則繼續檢驗，放棄與列表中低優先級匹配的校驗，並釋放這個對話。這種基於優先級限制每個優先級只對應一個FC的觸發方式，可以在一定程度上解決共享觸發類的業務衝突問題。
這種iFC觸發機制的功能較爲薄弱，它按照靜態的優先級依次觸發各個AS，因此難以處理多個業務交互的情況。具體來說，它存在的不足之處如下。
●靜態性：iFC機制在初始請求到來的時候，按靜態配置好的順序觸發相關AS，而無法根據業務的觸發情況、會話的進展動態地觸發AS。
●使用範圍有限：只能依據目前的5類觸發點來判斷是否觸發一個業務，然而除此之外尚有許多因素可作爲觸發點，例如：終端能力、用戶偏好、時間因素、前一個業務執行情況等。
●表達能力有限：iFC只能按照規定的優先級順序觸發AS，實現簡單的業務組合，而對於實現複雜的業務組合則無能爲力，例如它無法將Presence業務和補充業務有效結合起來，根據用戶不同Presence狀態調用不同的補充業務。
●缺乏在線規避業務衝突的手段：iFC簡單的順序觸發方式沒有考慮AS之間的衝突問題，在這種情況下，相互衝突的業務可以在同一次會話中觸發，影響用戶體驗。
3、SCIM研究和應用現狀
爲了有效控制和處理IMS中存在的業務交互問題，3GPP在IMS體系中引入一個新的網元——SCIM來專門負責協調業務運行，有時又稱爲Service Broker。SCIM最早出現在TS 23.218規範。在規範中，SCIM作爲一種特殊的AS或者作爲AS中的特殊功能實體，但是除了此概念以外，缺乏更進一步的定義以及關於SCIM的功能結構和實現方式的說明。
由於業務交互問題本身也較爲複雜，業界缺乏對SCIM的統一認識和理解，所以不同廠商和研究人員從不同的角度對SCIM提出了自己的理解，其中以Michael Palmeter觀點較有代表性，他把SCIM分爲以下5類。
●AS Internal Function：SCIM作爲AS內部的功能，作爲requestdispatcher存在。SCIM作爲SIP AS的對外訪問入口，根據收到的SIP請求有選擇地調用各個業務。這種機制與AS的實現方式相關，是私有的，大部分SIP應用服務器都會提供類似的功能。
●SIP Broker：主要用於在外部管理SIP應用服務器之間的交互，可能有複雜的路由和排序規則引擎，其功能類似於S-CSCF的業務觸發功能。
●Service Broker：解決業務能力的交互問題，業務能力需要使用WSDL和SOAP抽象並開放出來，SCIM將業務之間的交互看作是業務流程組合。
●Legacy/NGN：解決SIP和傳統信令系統之間的交互。傳統系統接口之間的區別很大，業務實現基於網絡設備商的私有平臺，因此這種SCIM估計不會是一種通用的解決方案，這種SCIM除了觸發和路由機制外還需要有協議的映射機制。
●Service-Type Optimized：針對一種特定的服務類型而不是一組特定的實現技術進行了優化的SCIM。SCIM負責把特定的服務類型和一系列與其相關的服務組件集成，從而提供可定製的服務，例如，“電話”SCIM將與一些和電話相關的組件集成，這些組件支持媒體類型協商，用於電話的媒體服務器的控制、呼叫轉移、呼叫等待、呼叫保留等標準過程。“電話”SCIM可以用來專門提供和電話業務相關的業務組合能力。
3GPP組織對SCIM的功能和控制流程進行了進一步研究，在TR 23.810中對Service Broker（即SCIM）的功能需求以及部分交互流程的控制方式和改進方式提出了建議。
3.1 Service Broker的功能需求
從總體上說，Service Broker提供一個可管理、可控制的手段讓多個業務按照用戶預想的方式執行。它掌握用戶的業務訂購情況，明確這些業務該按照何種順序被觸發，並且能夠對存在衝突的業務進行協調。
對於Service Broker功能上的需求目前達成共識的主要有以下幾點：
●儘可能減小因Service Broker的引入而對IMS核心網造成的影響；
●Service Broker必須採用靈活的架構以便能夠應付新業務之間的交互問題；
●支持業務交互，即業務組合以及避免業務衝突；
●Service Broker應能夠管理IMS應用與非IMS應用之間的交互；
●支持傳統智能網與IMS業務的交互；
●支持不同接入方式的業務之間的交互，如UMTS、WiMAX、WLAN；
●支持SIP與非SIP業務之間交互；
●支持不同業務提供商的業務之間的交互；
●支持由用戶配置、控制業務交互的方式。
3.2 Service Broker實現方式
TR 23.810提出了Service Broker的3種實現方式，分別是集中控制、分佈式控制、混合式控制（如圖1～3所示）。
圖1 集中控制
集中控制方式由一個Service Broker來協調控制所有業務之間的交互，S-CSCF把Service Broker視爲AS，通過ISC接口與惟一的Service Broker聯繫，Service Broker與AS之間的接口仍然是ISC接口，這種方式容易實現，但是Service Broker容易成爲網絡中的瓶頸。
圖2 分佈式控制
分佈式控制方式爲每一個AS都配置一個Service Broker，S-CSCF把每個Service Broker都視作AS，通過ISC接口與其交互。S-CSCF將請求觸發給Service Broker，AS執行完後，Service Broker可以向S-CSCF發送sFC（subsequent filter criteria）以指示S-CSCF該如何觸發接下來的業務，這樣ServiceBroker可以根據衝突關係，動態地將後續業務排除出業務鏈，這種方式可以解決集中式方式的瓶頸問題，但是實現較爲複雜，控制流程也較難設計。
混合式控制結合了上述兩種方式，即有的Service Broker管理多個AS之間的業務交互，而有的Service Broker只和一個AS交互。在這種模式下，Service Broker不但要管理由它控制的AS之間的業務交互，還要管理屬於不同Service Broker的AS之間的業務交互。圖3（a）、（b）是兩種可能的實現方式。
圖3 混合控制
3.3 交互流程改進
影響SCIM實際應用的重要原因之一是SCIM的處理流程並不規範和統一，這不僅使SCIM對於業務交互的處理範圍、處理方式都“無章可循”，而且SCIM與網絡中其他實體之間也難以互通。TR 23.810中對部分實際遇到的交互問題提出了改進意見，這其中一部分改進可以由SCIM來完成，另一部分可以脫離SCIM，直接改進現網中的設備。
3.3.1 請求URI被修改的情況
SIP請求中的請求URI實際承擔着兩種角色：一是代表被服務的對象，被叫側S-CSCF根據請求URI中所指示的共有用戶標識進行iFC觸發；二是代表着會話的目的地址，S-CSCF根據請求URI所指示的共有用戶標識來進行路由，然而在業務觸發階段，某個AS可能改變了請求消息中的請求URI，結果S-CSCF將消息發往新的目的地，這導致後續本該被觸發的AS無法被正常觸發。因此，TR 23.810建議將請求URI所承擔的這兩種角色分離，S-CSCF根據當前服務URI進行業務觸發，針對目的地URI進行呼叫路由。
3.3.2 對衝突業務劃分等價類
在一次會話中觸發的業務之間可能存在着衝突，通過在iFC中引入指示業務之間衝突關係的信息，可以避免互相沖突的業務被引入到同一個會話中。實現方法是將所有的iFC按照所觸發的業務間的相容關係劃分爲若干個等價類，每條iFC中有專門的字段指示該iFC所屬的等價類，等價類之間可能存在衝突。S-CSCF在判斷是否觸發某條iFC之前，需要斷定是否有與該iFC所處等價類相沖突的某條iFC已經被執行，若已執行，則S-CSCF不能觸發目前的iFC。
此外，S-CSCF必須能夠判斷一個業務的觸發以及執行情況，以便確定衝突的業務是否已經執行。如果一個業務的iFC沒有被匹配，或者iFC匹配了，但是AS返回一個錯誤響應或者沒有返回響應，在這種情況下，S-CSCF視該業務執行失敗。另外，即使S-CSCF觸發了某個AS，並且AS也將請求消息返回給S-CSCF，也不能表明AS執行了該業務。因爲AS是否執行還可能取決於與具體業務相關的用戶數據配置情況。爲了判斷AS是否成功執行了業務，可以讓S-CSCF在觸發時添加一個標籤，如果AS成功執行，則在返回的請求消息中繼續保存該標籤，如果AS沒有執行，則在返回的請求消息中刪除該標籤，S-CSCF據此判定AS是否成功執行了業務，並判定下一個不相容的業務是否可以被觸發。
3.3.3 AS返回錯誤響應情況下的改進
當某個AS返回一個錯誤響應的時候，S-CSCF會立刻將響應送回主叫方，而不會繼續匹配剩下的iFC，後續原本可以執行的AS將由於之前AS的錯誤而失去了執行機會。然而在許多情況下，S-CSCF可以在前面的AS返回錯誤響應時，繼續觸發後續AS。爲此，可以在iFC中設置某個選項，以決定在先前AS返回錯誤響應時是否還要繼續觸發，若要繼續觸發，則S-CSCF將根據原始的請求消息對下一條iFC進行匹配。
3.3.4 擴充SPT
目前的SPT定義了5個觸發點類型，然而某些業務的觸發需要考察終端的能力，例如CSI業務，爲了解決這種情況下的問題，擴充了一個新的觸發點類型：終端能力。用戶在註冊過程中將終端能力通知S-CSCF，如果業務需要，S-CSCF可以檢查終端能力是否匹配。
3.3.5 攜帶觸發的業務信息
在一般情況下，一個AS中可以部署多個業務。iFC中只標明瞭應該觸發的AS的地址，而沒有指出具體業務名稱。這樣，當請求到達AS的時候，AS並不知道究竟該觸發哪一個業務。爲此，將iFC中AS地址改爲“業務名稱@AS”的形式，並將它放置於S-CSCF傳給AS消息的Route頭域中，AS根據業務名稱來觸發相應業務。
另外，如果用戶訂閱了一個AS中的多個業務，並且這些業務的iFC優先級是相鄰的，而S-CSCF針對每一個業務分別觸發一次，這樣消息將在S-CSCF與同一個AS之間來回多次，勢必造成不必要的延遲。因此可以考慮將原來各個業務的iFC歸併爲一條，一次性觸發AS將多個業務執行完畢後返回給S-CSCF。爲此，需要iFC添加一個項，指示AS中哪些業務應該被一次性執行以及執行順序。
4、結束語
業務交互問題是影響IMS實際部署和運營的一個重要問題。合理有效地解決業務交互問題，不僅可以快速、經濟地提供新業務，還可以減少業務之間的衝突，從正反兩方面共同提高用戶滿意度。但是，由於業務交互問題自身的複雜性，特別是業務衝突問題目前仍然處於研究階段，離實際應用還有一段距離。目前常採用的衝突檢測和解決方法仍然是通過人工方式識別衝突，然後修改業務邏輯或部署方式來解決，而業務協作方面的研究相對更爲成熟，所以如何通過SCIM來組合已有業務能力，是目前的研究熱點之一。