作为一类多方、高效的新业务，多方通话业务为运营商吸引高端客户提供了有效的手段，日益成为其投资建设的重点，本文所述的移动会议电话业务就属于此类业务，目前正以其不同以往的业务特征而得到日渐广泛的应用，移动会议电话业务的实现方式主要有两种：呼叫中心方式和智能网方式。从应用的角度看，智能网方式的实现方案由于计费灵活、流程控制简便而有更加广阔的应用前景。因此，设计一种基于智能网方式的会议电话业务方案便成为一个重要的研究课题。

一、移动会议电话业务智能网实现方案总体设计

根据市场需求分析，移动会议电话业务应具备以下业务特征：用户拨打统一业务接入码接入系统。安装语音流程，用户可选择预约会议或者召开即时会议。如用户选择预约会议，则需提前一定时间向系统预约所需要的会议资源（包括会议参会人数和会议延续时长），并需在其所预定的时间内参加会议。用户可通过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所示。

此外还需说明的是，记录开始时间节点和结束时间节点时，详细算法流程基本和上文的描述一致，若开始时间节点或结束时间节点不在数据库各记录中，则需重新插入该时间节点记录，同时注意该节点前后节点的数据修改。

四．结语
本文提出的移动会议电话业务设计方案已应用于中国移动宁夏智能网建设工程中，目前已进入试商用阶段。移动会议电话业务作为多方通话类业务的主推业务之一，它的设计实现和成功推出为基于智能网体系的多方通信业务的发展提供了更充分的依据，也使其他基于智能网的多方通信智能业务得到了快速、高效的推广。