一种新的业务冲突检测和解决方案

李 旭，胡国庆

(1.中国电子科技集团公司第五十四研究所，河北石家庄 050081;2.总参信息化部驻石家庄地区军事代表室，河北石家庄 050081)

0 引言

随着通信技术和网络技术的快速发展，能够融合多种异构网络、提供多媒体综合业务和开放网络资源能力的下一代网络体系结构逐渐形成。IP多媒体子系统(IP Multimedia Subsystem，IMS)是下一代网络的核心技术，IMS采用了控制和业务相分离的水平式分层架构。IMS既支持传统电信网、智能网的业务，又为新业务的开发和部署提供了开放的平台，从而进一步简化了第三方业务的开发和部署。实验证明，业务之间存在着特征交互，可能会延迟业务部署，从而给业务的快速提供带来不便。随着新业务的大量部署，在下一代网络中业务之间的特征交互问题将会更加突出。

1 业务冲突的研究现状

1.1 业务冲突解决方案

根据着眼点的不同，业务冲突的研究内容可以从2个角度进行归纳:①根据业务的生命周期将其分为离线(Off-Line)研究和在线(On-Line)研究2类;②根据业务冲突的研究目的将其分为避免(Avoidance)、检测(Detection)和解决(Resolution)3类。这2个方面的研究内容互为重叠，共同组成了业务冲突问题的整体解决方案。

1.2 业务冲突的解决方法

为了有效控制和处理IMS网络架构下的业务冲突检测与解决问题，3GPP在规范TS 23.218中，为IMS体系引入了业务能力交互管理器(Service Capability Interaction Manager，SCIM)来专门负责协调业务交互问题。之后，3GPP在TR 23.810中又引入了Service Broker功能实体。总体来说，Service Broker提供了一个可管理、可控制的手段让多个业务能够按照用户预想的方式执行，根据用户业务的签约情况，明确这些业务的触发顺序，并对存在的业务冲突进行协调。但是3GPP对SCIM和Service Broker仅提出了概念，并没有进一步的定义，也没有给出具体的功能结构和实现方式的说明。

文献［3］提出了一种解决离线业务冲突的方法，定义了业务的描述方式以及检测业务冲突的准则。通过比较2个业务的描述信息进行冲突检测，一旦发现冲突，就采用事先定义的解决算法选择一个业务来执行。这种方法主要局限于离线业务冲突的检测和解决，不能处理在线的业务冲突。文献［4－7］介绍了 Lucent Service Broker的设计方案。Lucent Service Broker的消息处理逻辑是由Steplets控制的，Steplets是可以动态加载的程序片段。Lucent Service Broker是一种层次化架构:最核心的部分是Steplets集合;在此之上由SIP层和HTTP层调用Steplets协调业务关系。文献［8，9］介绍了一种基于免疫学的多层防护业务冲突检测规则和管理系统，将免疫识别过程中的一些重要原理(抗原识别、协同刺激和克隆选择等)借鉴到业务冲突的在线检测和解决中，对业务冲突具有较好的适应性和扩展性。然而由于专家经验知识有限和业务冲突问题本身的复杂性，这种方法往往存在较大的漏报和误报。

2 一种新的Service Broker的设计方案

2.1 Service Broker架构图

Service Broker位于S-CSCF与AS之间，Service Broker与S-CSCF和AS进行交互，如图1所示。通过对上述文献的分析，设计了一个新的 Service Broker架构，如图2所示。

图1 Service Broker在IMS中的位置

图2 一种新的Service Broker架构

架构主要包括:呼叫控制模块和核心处理模块2个模块。呼叫控制模块接收来自S-CSCF和应用服务器的SIP消息，并通过与核心控制模块的交互获得系统内部的消息;通过消息分类功能将消息交给不同的消息处理模块进行处理;当收到S-CSCF会话建立的消息时，呼叫控制模块记录该消息的会话ID并初始化状态机以跟踪会话状态，然后将消息发送到核心处理模块进行冲突检测，当核心处理模块指示业务触发完毕或业务冲突导致无法继续执行业务时，由会话管理模块负责寻找默认的S-CSCF地址进行转发;当收到来自AS的消息时，将此消息发送到核心处理模块进行冲突检测从而判定是否需要继续触发业务。

核心处理模块通过与呼叫控制模块交互，并利用冲突检测模块提供的接口，控制完成IMS系统中用户订阅的一组业务的业务触发及冲突检测和处理。接收会话控制模块的调用，从传入的消息中获得本次的会话 ID，读取对话的触发阶段 Trigger-Stage和已触发业务列表Service-List，据此将消息分发到不同的模块进行处理;首先调用业务触发接口，然后调用冲突检测接口，如果有冲突则继续调用业务触发接口;通过业务触发接口查询用户的自定义规则和初始过滤准则(initial Filter Criteria，iFC)文件查询下一个需要触发的业务编号返回给调用接口;业务冲突检测模块则通过离线业务冲突和在线业务冲突管理子模块对业务冲突进行检测和解决。

2.2 业务冲突检测子模块

Service Broker分析和研究的重点就是业务冲突检测子模块，主要包括:离线业务冲突检测模块和在线业务冲突检测模块2个部分。业务冲突检测子模块如图3所示。

图3 业务冲突检测子模块

离线冲突管理模块负责离线业务冲突的检测和解决，离线冲突检测模块由离线规则库和离线业务冲突检测算法组成。借鉴传统的二维表业务冲突检测方法，在这里把传统的静态二维表扩展成动态二维表。

动态二维表冲突检测算法的原理:在静态二维表的基础上增加了发现冲突时的执行策略，即在发现冲突时，根据预先设定的方案解决该业务冲突。如果业务之间没有冲突，则依次进行触发。处理流程如下:

①当系统启动时，将业务二维表从数据库中调入到内存中，完成数据的初始化存储;

②根据用户文档，核心处理模块得知会话将要触发的业务，由动态二维分析表来检查这些业务之间是否存在业务冲突;

③如果存在冲突，则根据预先制定的解决方案来解决该业务冲突;

④如果没检测到业务冲突则将用户请求消息交给在线业务冲突管理器进一步处理。

在线冲突管理模块由在线规则库业务冲突分类模块和循环冲突检测算法组成。根据在线规则库判断该业务是否存在冲突;然后通过业务冲突分类模块判断是否为循环业务冲突;如果不是，就把该业务冲突信息返回给离线冲突检测模块，扩展动态二维表;如果是循环冲突，就采用循环检测算法进行业务冲突检测。

循环冲突检测算法的原理:在系统中保存2个字段(Source-List和Destination-List)的定义，Source-List保存每次转发时的源地址列表，每次转发时把源地址和最终目的地址添加到Source-List末尾。Destination-List保存每次转发时的下一跳地址列表，每次转发时添加下一跳地址和最终目的地址到列表。若

即Destination-List列表中的地址集合是Source-List列表中的子集，则认为出现循环，即检测到冲突。然后对其该消息，并释放会话，结束本次冲突检测。

3 实验结果

为了验证该Service Broker架构检测解决业务冲突的有效性，按照图4所示验证平台进行了试验验证，将 X-Lite软终端(A、B、C)、CSCF服务器、HSS、SIP服务器和 Service Broker连接到交换机。在SIP服务器上部署了2个业务:呼叫前转业务和呼叫代答业务。

图4 Service Broker验证平台

情景1:设用户B同时订阅了呼叫代答业务和呼叫前转业务，用户B注册为呼叫前转用户C。

用户A呼叫用户B，首先在离线业务冲突检测模块中调用动态二维表算法，检测到呼叫代答和呼叫前转业务之间存在冲突。根据预先制定的策略执行呼叫前转业务。

情景2:设用户A、B、C均订阅了呼叫前转业务，其中用户A注册为呼叫前转用户B，用户B注册为呼叫前转用户C，用户C注册为呼叫前转用户A。这是一个典型的活锁类业务冲突。

当用户A、B、C中的任何一个用户拨打其中的另外一个用户时，首先在离线业务冲突检测模块中调用动态二维表算法，没有检测到业务冲突，然后将业务请求消息转交给在线冲突检测模块;在线冲突检测模块调用循环冲突检测算法，求出Source-List={A，B，C}，Destination-List={B，C，A}，因为

即Destination-List是Source-List的子集，由此判断出本次呼叫存在活锁类业务冲突，放弃本次会话。

4 结束语

依据3GPP针对SCIM和Service Broker提出的功能需求，参考现有的业务冲突检测和解决方法，提出了一个Service Broker架构。该架构的业务冲突检测子模块对业务冲突采用二级检测，先对离线业务冲突进行检测，然后对在线业务冲突进行检测和解决。通过动态二维分析表方法进行离线业务冲突检测和解决;通过循环检测算法进行在线业务冲突的检测和处理。并通过离线规则库和在线规则库之间的交互对动态二维表进行扩展，以解决新的业务冲突。该架构能够提高业务冲突检测的效率和成功率。 ■

［1］3GPP TS 23.218.IP Multimedia(IM)Session Handling;IM Call Model［S］.

［2］3GPP TR 23.810.Study on Architecture Impacts of Service Brokering［S］.

［3］KOLBERG M， MAGILL E H. Managing Feature Interactions between Distributed SIP Call Control Services［J］.Computer Networks，2007，51(2):536 －557.

［4］ANUPAM V，HULL R B，KANWAL S S，et al.An Introduction to Lucent’s Service Enhancement Layer［J］.Bell Labs Technical Journal，2006，10(4):179 －196.

［5］DEVITO N M，EMERY R T，KOCAN K F，et al.Functionality and Structure of the Service Broker in Advanced Service Architectures［J］.Bell Labs Technical Journal，2005，10(1):17 －30.

［6］KOCAN KF，ROOMEWD，ANUPAMV.Service Capability Interaction Management in IMS Using the Lucent Service Broker Product［J］.Bell Labs Technical Journal，2006，10(4)，217 －232.

［7］KOCAN K F，ROOME W D，ANUPAM V.A Novel Software Approach for Service Brokering in Advanced Service Architectures ［J］.Bell Labs Technical Journal，2006，11(1):5 －20.

［8］魏 薇，杨放春.基于免疫学的多层防护业务冲突管理系统研究［J］.高技术通讯，2007，17(4):362 －367.

［9］魏 薇，杨放春.基于免疫学的多层防护业务冲突检测方法［J］.电子与信息学报，2007，29(10):2455－2459.