李廣宇 王純 劉國輝

（1 北京郵電大學網(wǎng)絡與交換技術(shù)國家重點實驗室 北京 100876)

(2 東信北郵信息技術(shù)有限公司 北京 100191）

1 引言

隨著3G時代的到來，人們對通信業(yè)務的需求不再滿足于單純的通話服務，而是渴望擁有一種能融合語音、數(shù)據(jù)與多媒體等技術(shù)的新業(yè)務。簡單的“投資建網(wǎng)—放號—收入”的增長模式已經(jīng)無法滿足用戶的通信需要。通信網(wǎng)絡的建設必須能夠很好地和產(chǎn)業(yè)鏈的建設結(jié)合在一起，以形成良性的商業(yè)模式。隨著全業(yè)務運營時代的到來，必然要求在網(wǎng)絡和業(yè)務層面全面實現(xiàn)融合，為了滿足人們的這一需求，融合通信IMS（IP Multimedia Subsystem）業(yè)務應運而生。

IMS最初是3GPP組織制定的3G網(wǎng)絡核心技術(shù)標準，3GPP2（The Third Generation Partnership Project 2）、IETF（Internet Engineering Task Force）、ITU-T（ITU Telecommunication Standardization Sector）、TISPAN（Telecommunication and Internetconverged Services and Protocols for Advanced Networking）、OMA（Open Mobile Alliance）、ATIS（The Alliance for Telecommunications Industry Solutions）等重要標準化組織也都積極參與到IMS標準化工作中。IMS作為今后的網(wǎng)絡發(fā)展方向，為采用分組接入的移動和固定用戶提供統(tǒng)一的業(yè)務控制，在業(yè)界已基本達成共識。經(jīng)過多年的發(fā)展，IMS技術(shù)基本成熟。運營商已經(jīng)開始部署IMS網(wǎng)絡，為分組域接入的固定和移動用戶提供各種IP多媒體業(yè)務，如VoIP、IP Centrex、彩鈴/彩振、IM/PS、多媒體會議等。

為了節(jié)約改造成本，由2G網(wǎng)絡平滑演進到IMS網(wǎng)絡，各業(yè)務平臺提供商提出通過改進原有智能網(wǎng)系統(tǒng)增加SIP協(xié)議、計費Rf接口等，來支持IMS業(yè)務和IMS用戶的計費，并能夠保證原有智能網(wǎng)用戶的業(yè)務功能和計費。將SCP（Service Control Point）改造為B2BUA（Back to Back User Agent），正如其名字所述，一個B2BUA中的UAS（User Agent Server）和UAC（User Agent Client）粘合在一起。UAS作為正常的UAS終止請求；而UAC發(fā)起一個新請求，該請求以某種方式與UAS側(cè)收到的請求相關(guān)，但不按照特定協(xié)議鏈接。

2 原有智能網(wǎng)業(yè)務處理機制

根 據(jù) INCM（Intelligent Network Conceptual Model）將智能網(wǎng)分成4個層面，每個層面代表從不同角度所提供的網(wǎng)絡能力，從上至下依次為：業(yè)務平面（Service Plane）、整體功能平面（Global Functional Plane）、 分 布 功 能 平 面（Distributed Functional Plane）和物理平面（Physical Plane）。在整體功能平面，將實現(xiàn)業(yè)務的基本功能分成獨立于業(yè)務的積木式組件SIB（Service Independent Building Block），如運算、篩選、計費、限制翻譯等。按照整體業(yè)務邏輯（GSL，Global Service Logic）要求的次序?qū)⒏鱏IB鏈接在一起形成一個完整的業(yè)務。

SCP是智能網(wǎng)中的核心網(wǎng)元，主要完成對電信網(wǎng)中的智能呼叫業(yè)務進行信令控制、計費管理和數(shù)據(jù)統(tǒng)計等功能。SCP提供多種業(yè)務邏輯的執(zhí)行環(huán)境，存儲業(yè)務數(shù)據(jù)和業(yè)務邏輯，針對不同的智能業(yè)務選擇和執(zhí)行相應的業(yè)務邏輯，控制業(yè)務交換點（SSP，Service Switching Point）的動作，以實現(xiàn)智能業(yè)務的執(zhí)行和控制。業(yè)務生成環(huán)境，通過SCP提供的SIB接口，完成業(yè)務定義和開發(fā)。

SCP采用如圖1所示的消息驅(qū)動機制驅(qū)動業(yè)務邏輯執(zhí)行, 即每一個業(yè)務邏輯實例的動態(tài)執(zhí)行過程都抽象成一個呼叫狀態(tài)自動機，自動機的狀態(tài)改變由消息來驅(qū)動，同時存在大量的自動機。SCP中使用對話號唯一標識一個呼叫，當交換機將一個智能呼叫觸發(fā)到SCP后，SCP內(nèi)部將產(chǎn)生一個與該呼叫相關(guān)的自動機，并以對話號標識該自動機。SCP將所有消息進行緩沖，并順序的對準備發(fā)往各個自動機的消息進行處理，每個消息的處理促使某個自動機執(zhí)行一個SIB，一個呼叫的所有消息的處理過程，就等同于一個業(yè)務邏輯的執(zhí)行過程。由于消息緩沖隊列不區(qū)分目的自動機而將消息順序排隊，雖然可以同時處理多個呼叫，但其實為偽并發(fā)方式，并不是真正意義的并發(fā)方式。

圖1 SCP中的消息驅(qū)動機制模型

3 原有業(yè)務開發(fā)模式用于IMS業(yè)務的缺陷

智能網(wǎng)業(yè)務中，信令流程固定，業(yè)務執(zhí)行也相對固定，業(yè)務功能容易抽象，原有的業(yè)務開發(fā)模式，非常適合智能網(wǎng)業(yè)務。但是用于IMS業(yè)務卻有諸多弊端。

3.1 內(nèi)部消息增多

SIP基于文本的方式，使各種擴充工作變得十分簡單。強大的擴充機制，使SIP的能力不斷增強。對于同一種情況，由于消息所攜帶的參數(shù)不同，會導致后續(xù)業(yè)務流程變化。

比如IMS業(yè)務臨時響應可靠性問題：當初始INVITE中沒有Support 100rel(Support頭，里面有個100rel選項)，后續(xù)的1xx消息(100除外)，不能攜帶Require 100rel(Require頭，里面有100rel選項)。

當初始INVITE中有Support 100rel時，后續(xù)的1xx消息(100除外)，可以攜帶Require 100rel，也可以不帶。當1xx中攜帶Require 100rel時，表示該1xx響應需要保證傳輸可靠性，對端需要回復PRACK。當1xx不攜帶Require 100rel，即這條臨時響應不需要保證可靠傳輸，不需要回復PRACK。

當初始INVITE中帶有Require 100rel時，后續(xù)的1xx消息(100除外)，必須攜帶Require 100rel，而發(fā)起INVITE的UAC也必須回復PRACK。

以上的例子在IMS業(yè)務中還有很多，如此便要在業(yè)務中增加大量的邏輯判斷SIB來分析業(yè)務的下一步流程，無疑將增加相應數(shù)量的內(nèi)部消息驅(qū)動SIB之間的轉(zhuǎn)換。內(nèi)部消息的增多，會消耗更多的系統(tǒng)資源，并大大降低軟件的性能。

3.2 消息響應能力有限

智能網(wǎng)信令流程固定，即自動機在一定狀態(tài)下收發(fā)的消息是固定的，只是攜帶的參數(shù)內(nèi)容不同，一個SIB只需要處理一個會話的一種消息。而IMS業(yè)務非常靈活，信令流程相對復雜，在等待響應消息的時候，下一條消息有不確定性。

比如UE-A（User Equipment-A）、UE-B（User Equipment-B）、UE-C（User Equipment-C） 三 方通話業(yè)務，用戶UE-A撥打用戶UE-B的號碼，雙方通話建立，用戶UE-A需要保持用戶UE-B；用戶UE-A撥打用戶UE-C的號碼，雙方通話建立，用戶UE-A再執(zhí)行操作，進入三方會議狀態(tài)。這個流程中需要同時維持兩個會話，用戶UE-B在等待中可能會有其它的操作。

SCP需要同時維持兩個會話，隨時準備接受雙方的信令，這對于原有SIB串行的處理方式都是極難實現(xiàn)的。

3.3 字符串的處理能力有限

SIP基于文本的方式，在消息類型、消息頭、消息體3個消息的基本部分上都可以被不斷擴充，導致SIP消息有大量的參數(shù)，從而對于字符串類型的處理大量增加。對于構(gòu)造SIP消息，一個算法SIB的處理能力有限，必須采用增加算法SIB或者循環(huán)操作算法SIB的方式實現(xiàn)，這樣都無疑增加了SIB的數(shù)量，同時增加了處理內(nèi)部消息的開銷。

3.4 業(yè)務編寫能力有限

SCP提供類似腳本的語言用于編寫業(yè)務，使用的數(shù)據(jù)類型均為在C語言基礎(chǔ)上進行定義，并對一些資源進行了預先分配。IMS業(yè)務對數(shù)據(jù)類型的需要更為靈活，原有的開發(fā)模式只有通過不斷的完善才能勉強符合其要求。流程的復雜也造成了SIB數(shù)量的增加，對于業(yè)務邏輯的編寫、維護和功能擴展都帶來了難度。

4 新的開發(fā)模式

由于原有業(yè)務開發(fā)模式對于IMS業(yè)務的開發(fā)有上述問題，所以在原有的業(yè)務開發(fā)模式基礎(chǔ)上，提出一種新的業(yè)務開發(fā)模式，能夠解決上述缺陷。

新的業(yè)務開發(fā)模式以C++語言作為業(yè)務的開發(fā)語言，為業(yè)務開發(fā)者提供統(tǒng)一的消息接口，將各種協(xié)議的消息抽象為一個統(tǒng)一的消息結(jié)構(gòu)，并提供統(tǒng)一的接口以實現(xiàn)對消息參數(shù)的讀寫功能。業(yè)務的執(zhí)行環(huán)境基于多線程設計，采用“預先創(chuàng)建，動態(tài)加載”的方式使用線程，即通過創(chuàng)建線程池，動態(tài)加載線程，使用完后，并將線程放入線程池中，以待其它會話使用。主線程從消息隊列中取得消息并派發(fā)給業(yè)務執(zhí)行子線程，當子線程收到外部消息后，將外部消息解碼為統(tǒng)一消息結(jié)構(gòu)，供業(yè)務使用。業(yè)務判斷消息類型，根據(jù)消息的參數(shù)選擇相應的業(yè)務流程，并記錄下消息類型以及業(yè)務狀態(tài)等信息。當業(yè)務發(fā)送消息時，子線程將統(tǒng)一消息結(jié)構(gòu)編碼為外部消息發(fā)送到消息隊列，由主線程負責將此消息發(fā)送到外部實體。

4.1 總體結(jié)構(gòu)

總體結(jié)構(gòu)如圖2所示。主要分為業(yè)務開發(fā)和執(zhí)行接口模塊、消息編解碼模塊、消息組件管理模塊和業(yè)務邏輯執(zhí)行模塊。其中業(yè)務開發(fā)和執(zhí)行接口模塊是整個業(yè)務邏輯執(zhí)行環(huán)境中最主要的模塊，由它負責消息的收發(fā)、對其它模塊的調(diào)用，并且為業(yè)務邏輯的開發(fā)提供了系統(tǒng)接口。消息編解碼模塊、消息組件管理模塊和業(yè)務邏輯執(zhí)行模塊分別負責消息編解碼、消息參數(shù)檢查保存及修改和業(yè)務邏輯執(zhí)行，這3個模塊都會調(diào)用消息接口模塊的接口對消息參數(shù)進行讀寫操作，消息接口模塊主要提供消息存儲和參數(shù)讀寫功能。

圖2 總體結(jié)構(gòu)圖

4.2 流程描述

在原系統(tǒng)的基礎(chǔ)上，仍沿用自動機機制。當自動機收到消息（定義為TMsg）后，根據(jù)消息類型判斷是否初始化C++業(yè)務執(zhí)行環(huán)境處理，如果此自動機已經(jīng)存在C++業(yè)務執(zhí)行環(huán)境則將消息派發(fā)給業(yè)務執(zhí)行環(huán)境。業(yè)務執(zhí)行環(huán)境在收到外部消息后，調(diào)用消息編解碼模塊的解碼函數(shù)將消息解碼為統(tǒng)一消息結(jié)構(gòu)（定義為TLibMsg），然后消息組件管理模塊接收TLibMsg并檢查消息參數(shù)和保存必要參數(shù)，最后業(yè)務邏輯執(zhí)行模塊接收TLibMsg讀取業(yè)務所需要的參數(shù)并進行一系列的處理；當業(yè)務向外部實體發(fā)送消息時，首先構(gòu)造一條TlibMsg并設置相應的參數(shù)并將此消息發(fā)送到消息組件管理模塊，然后消息組件管理模塊對一些參數(shù)做修改并將消息發(fā)送給編解碼模塊，編解碼模塊將消息編碼為外部消息TMsg并將消息發(fā)送給消息接口模塊，消息接口模塊將外部消息寫到消息隊列中，由主線程負責將消息發(fā)送到外部實體。數(shù)據(jù)流圖如圖3所示。

5 新業(yè)務開發(fā)模式的優(yōu)勢

此業(yè)務開發(fā)模式仍然采用消息驅(qū)動的機制，但SIB概念的淡化，減少了內(nèi)部消息的使用，減少了消息排隊時間，也減少了任務切換開銷；消息的響應處理更為靈活，一個自動機狀態(tài)可以處理多種消息；由于多線程機制的引用，同時有多個線程并發(fā)的對消息進行處理，再配以原有多進程的方式，使得消息在消息隊列中的等待時間大大降低，能夠有效降低呼叫響應時長；采用C++語言開發(fā)業(yè)務，業(yè)務層能夠使用的運算符和數(shù)據(jù)結(jié)構(gòu)更為豐富，業(yè)務的設計自由度增大，同時因為更貼近于系統(tǒng)底層，業(yè)務的執(zhí)行效率也被大大的提高。

圖3 數(shù)據(jù)流圖

[1] Mayer G，Khartabil H等. IMS：移動領(lǐng)域的IP多媒體概念和服務．北京：機械工業(yè)出版社，2005

[2] 廖建新，王晶，郭力等．移動智能網(wǎng)．北京：北京郵電大學出版社，2000

[3] Zhang L，Liao J X，Chen J L，The Analysis of Service Triggering Mechanism in Intelligent Network，2003 International Conference on Communication Technology： 1730-1733

[4] 黃健. 移動智能網(wǎng)SCP多進程方式的設計與實現(xiàn). 北京郵電大學碩士學位論文，2004年2月

[5] 3GPP TS23.228 v7.3.0 IP Multimedia Subsystem(IMS) Stage2 (Release-7). Mar 2006

[6] 中國移動CM-IMS統(tǒng)一Centrex業(yè)務總體技術(shù)要求V1.0.0_20100225.北京：中國移動通信集團公司

[7] 張智江等．SIP協(xié)議及應用．北京：電子工業(yè)出版社，2005

[8] 張亮，CMIN02-SCP系統(tǒng)呼叫接續(xù)時長優(yōu)化. 北京郵電大學碩士學位論文，2009年2月