一种新的智能网业务开发模式*

李广宇 王纯 刘国辉

（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月