一種新的智能網業務開發模式*

李廣宇 王純 劉國輝

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

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

1 引言

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

IMS最初是3GPP組織制定的3G網絡核心技術標準，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作為今后的網絡發展方向，為采用分組接入的移動和固定用戶提供統一的業務控制，在業界已基本達成共識。經過多年的發展，IMS技術基本成熟。運營商已經開始部署IMS網絡，為分組域接入的固定和移動用戶提供各種IP多媒體業務，如VoIP、IP Centrex、彩鈴/彩振、IM/PS、多媒體會議等。

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

2 原有智能網業務處理機制

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

SCP是智能網中的核心網元，主要完成對電信網中的智能呼叫業務進行信令控制、計費管理和數據統計等功能。SCP提供多種業務邏輯的執行環境，存儲業務數據和業務邏輯，針對不同的智能業務選擇和執行相應的業務邏輯，控制業務交換點（SSP，Service Switching Point）的動作，以實現智能業務的執行和控制。業務生成環境，通過SCP提供的SIB接口，完成業務定義和開發。

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

圖1 SCP中的消息驅動機制模型

3 原有業務開發模式用于IMS業務的缺陷

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

3.1 內部消息增多

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

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

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

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

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

3.2 消息響應能力有限

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

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

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

3.3 字符串的處理能力有限

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

3.4 業務編寫能力有限

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

4 新的開發模式

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

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

4.1 總體結構

總體結構如圖2所示。主要分為業務開發和執行接口模塊、消息編解碼模塊、消息組件管理模塊和業務邏輯執行模塊。其中業務開發和執行接口模塊是整個業務邏輯執行環境中最主要的模塊，由它負責消息的收發、對其它模塊的調用，并且為業務邏輯的開發提供了系統接口。消息編解碼模塊、消息組件管理模塊和業務邏輯執行模塊分別負責消息編解碼、消息參數檢查保存及修改和業務邏輯執行，這3個模塊都會調用消息接口模塊的接口對消息參數進行讀寫操作，消息接口模塊主要提供消息存儲和參數讀寫功能。

圖2 總體結構圖

4.2 流程描述

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

5 新業務開發模式的優勢

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

圖3 數據流圖

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

[2] 廖建新，王晶，郭力等．移動智能網．北京：北京郵電大學出版社，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] 黃健. 移動智能網SCP多進程方式的設計與實現. 北京郵電大學碩士學位論文，2004年2月

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

[6] 中國移動CM-IMS統一Centrex業務總體技術要求V1.0.0_20100225.北京：中國移動通信集團公司

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

[8] 張亮，CMIN02-SCP系統呼叫接續時長優化. 北京郵電大學碩士學位論文，2009年2月