作為一類多方、高效的新業務，多方通話業務為運營商吸引高端客戶提供了有效的手段，日益成為其投資建設的重點，本文所述的移動會議電話業務就屬于此類業務，目前正以其不同以往的業務特征而得到日漸廣泛的應用，移動會議電話業務的實現方式主要有兩種：呼叫中心方式和智能網方式。從應用的角度看，智能網方式的實現方案由于計費靈活、流程控制簡便而有更加廣闊的應用前景。因此，設計一種基于智能網方式的會議電話業務方案便成為一個重要的研究課題。

一、移動會議電話業務智能網實現方案總體設計

根據市場需求分析，移動會議電話業務應具備以下業務特征：用戶撥打統一業務接入碼接入系統。安裝語音流程，用戶可選擇預約會議或者召開即時會議。如用戶選擇預約會議，則需提前一定時間向系統預約所需要的會議資源（包括會議參會人數和會議延續時長），并需在其所預定的時間內參加會議。用戶可通過WEB界面或語音流程進行會議的預約、查詢、修改、撤銷、管理等操作，通過語音方式參與會議。

在組成結構與實現方式上，移動智能網嘲實現的會議電話業務與其他非多方通話類業務相似：將新的網元——智能外設(IP)加入到智能網系統中可以完成多個話路的連接，從而實現多方通話功能。智能外設在智能網系統中的位置和接口設計見圖1。其功能舉例如下：某用戶要參與會議的流程，其撥打接入號碼的呼叫自業務交換點(SSP)上報到業務控制點(SCP)后，經SCP鑒權，由智能外設負責將多方話路接續起來，會議結束后由SCP負責為用戶計費。

智能外設通過SSP發來的ISDN用戶部分(ISUP)消息呼叫請求來控制話路的接續和拆除，并根據ISUP消息參數中的相關數據建立與SCP的事物處理應用部分(TCAP)的交互，接受SCP的智能業務操作指示。專用資源功能(SRF)節點的系統模型設計如圖2所示。

接入終端console與管理維護平臺(AM)處于管理層，當需要更新資源節點(RN)中的數據時，console(或業務管理點(SMP)、網管中心、維護中心)只需向AM發送一條命令。然后AM向每個RN發送同樣的命令來更新數據。AM與智能外設內部的控制節點(CN)、七號信令處理功能(realSS7)、RN、console實體之間具有TCP/IP接口，與外部的SMP、維護中心、網管中心實體之間有TCPAP接口。

SMP、維護中心、網管中心實體之間有TCPAP接口。CN處于控制層，它通過控制消息指示RN執行由SSP上報的ISUP消息中所指定話路時隙上的放音(PA)、放音并收號(P&C)、放音并收集用戶語音信息(P&R)、釋放指定語音消息(EM)、執行一個腳本(ScriptRun)、關閉一個正在執行的腳本(ScriptClose)等操作，并將結果返回給SCP。隨后切斷與SCP和SSP的連接，釋放相應資源，SCP繼續其他智能業務。

基于如上設計方案，需解決兩個關鍵技術問題：如何實現多條話路的接續和話路資源的合理分配。這兩個問題將在后文展開論述。

二、移動含議電話業秀智能網互聯體系結構設計
1．智能外設的功能設計
作為智能網系統中一個重要的功能實體，獨立智能外設(IIP)在智能網中實現智能外設的功能。下面從會議的周期角度來說明IIP的實體功能：當業務鑒權完成之后，SCP下發ScriptRun消息到IIP，觸發IIP的一個執行腳本，標志會議開始。當用戶選擇結束會議并退出時，IIP向SCP發ScriptEvent消息，標志會議結束。

IIP可以實現會議的多方話路接續功能，呼入的多條話路經由某種路由算法所控制的相應硬件板卡接入到某一指定的會議中。數字信號處理(DSP)技術用來控制這些話路上數據的正常雙向傳輸。此外，會議板卡還具有對所聯入話路上的信號進行混音和回聲抑制的功能，從而保證了話音質量。

2．各智能實體間的接口設計

(1)SCP與IIP間的UIScript接口設計

用戶交互腳本(UIScript：User Interaction Script)接口是在CS2中定義的用于SCP與IIP之間通信的標準智能網應用部分(INAP)信令，包括四種主要操作原語： ScriptRun、Scriptlnformation、ScriptEvent、ScriptClose，分別在一次完整的SCP／IIP交互過程的不同階段應用。

(2)SMP與SCP、IIP間的接口設計

SMP與SCP、IIP間的接口是命令接口。用戶預約會議后，若會議時間已到則需要通知用戶，SMP掃描定時表會將表中的命令發往SCP或IIP。WWW側業務或SCP側業務在SMP的定時表中填寫命令并說明發送命令的時間和次數。一旦達到用戶指定的命令發送時間，SMP便將命令封裝并發到SCP底層。SCP將命令解包后，分析此命令體并得到相應的參數。SMP發送命令到IIP的處理過程與此類似。根據業務需要，設計如下命令(命令方向均為SMP到SCP)

?Confcard：申請會議卡后，向用戶發送短信通知卡號和密碼，然后加參數servicekey和meetingID，觸發SCP側短信流程；

?Confnotify：申請會議后，向主持人和與會者發送短信通知會議信息，然后加參servicekey和cardnumber，觸發SCP側短信流程；

?Cha~e：手工充值命令，然后加參數servicekey、accesscode、c~dnumber和phonenumber。

從SMP發向SRF(IIP)的命令為Invokescript：申請會議后，語音通知主持人和與會者，然后加參數servicekey，觸發IIP側業務流程。

三．預約含議的算法設計

會議預約是會議電話業務的一個重要功能。會議預約存在于主持人召開即時會議流程和預約會議流程中。會議預約的功能主要是為預約會議的用戶預約相應時間段內的會議資源。若該時間段內的會議資源充足，則預約成功；否則預約失敗。

預約算法的設計分為兩部分：資源的數據模型設計和資源占用的算法設計。

(1)資源的數據模型設計

資源的數據模型設計是指代表資源的數據結構的設計。將資源抽象為何種數據結構將對資源分配的算法起到決定性的作用，也是程序性能能否得到提高的關鍵。資源的數據模型設計有兩種方案。

第一，構造一個二維數組，線性描述某資源在任意時刻的分配情況。這種方案將資源對應到未來特定時間長度內的若干個以每一段固定長度的時間作為時間單位的記錄。若有用戶預約該資源，則將對應時間內的所有記錄標識為已被占用，并記錄其他信息。顯然這種方案采用的是靜態數組，優點是資源占用的算法很簡單，占用CPU資源也很少；缺點是為記錄資源的占用情況浪費了大量的空間。

第二，構造一個二維數組，非線性地描述資源在不特定時間內的分配情況。這種方案將資源對應到未來特定時間長度內的若干個以不同時間段長度為單位的記錄，將占用資源的各個時間點作為數據庫中記錄資源占用情況的各個節點，每個記錄描述從該時間
節點之后到下一時間節點前資源被占用的信息。與方案一不同，這種方案采用動態數組，將方案一中每一固定長時間段記錄一次資源占用情況改進為每有變化記錄一次資源占用情況。由此可見，方案二的優點就是大大節省了空間，但同時也帶來一些不可避免的缺點，例如資源占用的算法變得相對復雜，程序讀寫數據庫的次數相應增加，占用CPU資源相應增加等。

方案一將每段時間的描述均寫入數據庫，空間復雜度較大；而方案二只將不同時間點的描述寫入數據庫，空間復雜度較小。因此，盡管方案二的時間復雜度稍大，但現網應用中仍然采用方案二。

(2)基于方案二的資源占用算法的設計
方案二采用二維數組來描述特定資源在不特定時間內的分配情況，每個節點在數據庫中都以一個記錄的形式存在。因此，若干個這樣的記錄將描述出一段時間內資源的分配情況?；谶@種方案的資源占用算法其實質就是找到需預約會議的時間段內所有的時間節點，然后將這些節點標識為已被占用。例如，完成一個預約會議的流程，執行算法需要找到指定時間段內所有的時間節點，將這些節點的資源占用數加上該會議的資源占用數量，用以代表該資源已被這個會議所占用。
對該算法的具體描述如下：

第一步，得到在要求時間段內的所有節點。假設系統的資源容量為100，若預約8：00~11：00、10人參加的會議，首先需找到這段時間內的所有時間節點
A／B／C，如圖3所示。

第二步，得到這些節點對應的資源已占用數中的最大者，將之同本次資源占用數相加，并將相加所得的和與資源容量相比較，若前者小于后者，則認為可以占用該資源，即資源量滿足該會議的資源占用量，然后轉到第三步；否則認為資源不足，不可占用資源，因此要退出分配資源流程。在這個例子中，這些節點的最大資源占用數是3O，資源容量是100，而本次資
源占用量是10，因此資源量滿足該會議的資源占用量，接著轉到第三步；第三步，將所有滿足條件的節點的資源數都加該次會議的資源數。在本例中，將A／B／C時間節點的資源數加1O，如圖4所示。

此外還需說明的是，記錄開始時間節點和結束時間節點時，詳細算法流程基本和上文的描述一致，若開始時間節點或結束時間節點不在數據庫各記錄中，則需重新插入該時間節點記錄，同時注意該節點前后節點的數據修改。

四．結語
本文提出的移動會議電話業務設計方案已應用于中國移動寧夏智能網建設工程中，目前已進入試商用階段。移動會議電話業務作為多方通話類業務的主推業務之一，它的設計實現和成功推出為基于智能網體系的多方通信業務的發展提供了更充分的依據，也使其他基于智能網的多方通信智能業務得到了快速、高效的推廣。