CN100456699C - 通信网络中业务能力交互管理系统及其方法 - Google Patents

Abstract

本发明涉及通信领域，公开了一种通信网络中业务能力交互管理系统及其方法，使得通信网络中多业务交互和冲突问题得到解决，实现多业务能力交互管理功能。本发明中，通过设置service broker逻辑功能，处理AS之间的业务交互；在service broker中设置动态产生和消亡的仲裁者和全局管理者模块，仲裁者用于对应AS间的业务交互仲裁，管理者用于呼叫相关信息的维护，管理控制权的移交，并提供仲裁者查询信息，配置仲裁规则；引入业务状态转移机制和业务交互模型，包括悬挂、嵌套、中断和互斥等状态，和基于这些状态建立的解决多业务交互的实现机制。

Description

通信网络中业务能力交互管理系统及其方法

技术领域

本发明涉及通信领域，特别涉及通信网络中业务交互能力管理的实现技术。

背景技术

网际协议多媒体子系统(IP Multimedia Subsystem，简称“IMS”)是第三代移动通信合作伙伴项目(3rd Generation Partnership Project，简称“3GPP”)R5阶段提出的提供网际协议(Internet Protocol，简称“IP”)多媒体业务的子系统。它采用分组域为其上层控制信令和媒体传输的承载通道，并引入会话初始协议(Session Initial Protocol，简称“SIP”)作为业务控制协议，利用SIP简单、易扩展、媒体组合方便的特点，通过将业务控制与承载控制分离提供丰富的多媒体业务，是业界普遍认同的解决移动和固定网络融合的理想方案和发展方向。

IMS网络架构中的主要功能实体包括控制用户注册、会话等功能的呼叫会话控制功能实体(Call Session Control Function，简称“CSCF”)、集中管理用户签约数据的归属用户服务器(Home Subscriber Server，简称“HSS”)、提供各种业务逻辑控制功能的应用服务器(Application Server，简称“AS”)，其它还有多媒体资源控制功能实体(Multimedia Resource Control Function，简称“MGFC”)、策略判决功能实体(Policy Decision Function，简称“PDF”)等。其中CSCF按照角色功能又分为代理CSCF(Proxy-CSCF，简称“P-CSCF”)、查询CSCF(Interrogating-CSCF，简称“I-CSCF”)、服务CSCF(Serving-CSCF，简称“S-CSCF”)等类型，在逻辑功能上分别完成SIP会话路由中不同的功能，在物理上可以合一也可以分置。用户通过当前所在地代理节点P-CSCF接入IMS，会话和业务触发控制及与AS的业务控制交互则由其注册地的归属域服务节点S-CSCF完成，而I-CSCF则起到路由查询的作用。

IMS的提出是为了基于IP向用户提供更为优质、廉价的多媒体业务和应用。AS在业务提供过程中扮演了业务执行者的角色。业务的提供过程可分为下列四个步骤(这里假设从会话的发起侧考虑)：

1)IMS业务档案的下载，在用户注册的过程中，一个包含业务和用户相关数据的业务档案由HSS下载到服务于此用户S-CSCF中。业务档案中的初始过滤准则，包含了是否将用户的请求路由到相关的AS的触发信息。在这里，触发信息可能是根据请求消息的请求URI(例如一个语音信箱voice@ims.com)或请求的类型(如立即消息的MESSAGE请求)等来制定。

2)用户请求的生成，用户需要某种业务时，利用自己的设备生成相关的请求。例如，用户想要建立一个语音通话。他利用UE生成一个INVITE请求(包含请求URI，媒体描述等信息)，这条请求经P-CSCF，到达服务于他的S-CSCF。

3)AS的选择，用户的请求到达S-CSCF后，S-CSCF检索与请求的发起者匹配的业务档案。根据业务档案中的初始过滤准则，S-CSCF决定将请求路由到相应的AS或是直接进行转发。

4)AS执行相关的服务，在收到请求后，AS开始执行相关的服务。为了开展服务，AS可以工作在以下四种模式：终止UA-在这种模式下，AS充当了UE。比如，在消息类业务中，假设消息的接收方设置了某种过滤的准则，当其得到满足时，AS可能会代表接收方生成一个最终响应这时AS是作为一个SIP UA。

CSCF不再需要处理业务逻辑，而是通过基于规则的业务触发机制，根据用户的签约数据的初始过滤规则(initial Filtering Constraint，简称“iFC”)，由CSCF分析并触发到规则指定的应用服务器，由应用服务器完成业务逻辑处理。这样的方式下，使得IMS成为了一个真正意义上的控制层设备，与业务的藕合降低到最小。ISC接口基于SIP这一唯一的协议，这样更有利于业务的开放，同时由于IMS与业务做到了高度的独立，为新增业务而进行控制层设备大范围网络升级的情况将得到根本改观，业务的快速推出成为可能。

IMS作为下一代电信网络体系架构，必然是一种多业务的应用架构，在多业务应用的情况下，必然产生多种业务之间的协同性和一致性问题，先有的iFC触发机制所能解决的业务交互管理问题显然已经不能胜任将来多网融合、多业务种类并行的情况。多业务交互冲突所存在的问题不能得到解决，则严重阻碍下一代通信网络的演进。

目前业界提出的实现业务能力交互管理(Service Capability InteractionManager，简称“SCIM”)的功能实体，也被形象地称为业务经纪人(servicebroker)。所谓的Service broker的作用，就是提供多业务融合，解决多业务间的交互和可能出现的冲突问题，service broker的概念在IMS域内和域外都有所应用，但根本的焦点还是解决IMS域内各个AS的业务交互或冲突问题。到目前为止，service broker已经被引入了3GPP的相应规范，在OSA GW的相应规范中也有所体现。service broker的逻辑功能，可以位于AS上，也可以作为独立逻辑实体，3GPP引入SCIM，其位于AS上，其主要的作用就是完成service broker的功能。

目前3GPP还没有对service broker或SCIM给出具体的完整规范，各个主流厂家也还没有给出具体的技术实现。

发明内容

有鉴于此，本发明的主要目的在于提供一种通信网络中业务能力交互管理系统及其方法，使得通信网络中多业务交互和冲突问题得到解决，实现多业务能力交互管理功能。

为实现上述目的，本发明提供了一种通信网络中业务能力交互管理系统，包含一个管理者模块和至少一个仲裁者模块，

所述仲裁者模块用于在受本次呼叫产生的消息触发并获得控制权后，根据预先配置的规则和通过与所述管理者模块交互得到的本次呼叫相关信息，对本次呼叫产生的消息进行处理，并对本次呼叫产生的交互业务进行仲裁；

所述管理者模块用于管理所有呼叫相关信息，管理控制权的转交，通过与所述仲裁者模块交互以更新本次呼叫相关信息并向所述仲裁者提供查询。

其中，所述仲裁者模块对本次呼叫产生的交互业务进行仲裁时，修改本次呼叫产生的消息，并转发给根据仲裁结果决定的处理本次业务的应用服务器，然后修改所述业务的状态，并移交控制权给所述应用服务器。

此外在所述系统中，所述应用服务器根据所对应的业务的状态决定业务的动作，所述业务的状态包含悬挂、嵌套、中断、互斥，其中，

当两个交互业务的关系为嵌套且第一个业务嵌套在第二个业务中时，第一个业务处于嵌套状态并执行，第二个业务处于悬挂状态并暂停；

当两个交互业务的关系为中断且第一个业务中断第二个业务时，第一个业务处于中断状态并执行，第二个业务处于悬挂状态并暂停；

当两个交互业务的关系为互斥且第一个业务优先级高于第二个业务时，执行第一个业务，并终止第二个业务。

此外在所述系统中，所述管理者模块还用于给所述仲裁者模块配置所述规则、记录呼叫处理信息，并决定控制权在所述仲裁者模块及处理业务的应用服务器之间转交。

此外在所述系统中，所述管理者模块所管理的呼叫相关信息包含呼叫的处理过程、呼叫的业务拓扑结构、呼叫的注册业务信息、和呼叫的处理规则。

此外在所述系统中，所述仲裁者通过执行预先配置的脚本，对本次呼叫产生的交互业务进行仲裁。

此外在所述系统中，所述仲裁者在获得控制权后，执行脚本进行仲裁，先根据本次呼叫产生的消息和待仲裁业务，查找二维规则表，根据表项中规则条件与本次呼叫相关信息的匹配结果，执行仲裁。

此外在所述系统中，所述管理者模块控制所述仲裁者模块的产生与消亡，所述仲裁者模块在与其相关的消息触发时产生，在与其相关的交互业务终止后消亡。

本发明还提供了一种通信网络中业务能力交互管理方法，包含步骤：

A仲裁者模块受本次呼叫产生的消息触发，获得控制权；

B该仲裁者模块与管理者模块交互，得到本次呼叫相关信息；

C该仲裁者模块根据预先配置的规则及本次呼叫相关信息，对本次呼叫产生的消息进行处理，并对本次呼叫产生的交互业务进行仲裁；

D所述管理者模块更新本次呼叫相关信息。

其中，所述步骤C包含以下子步骤：

C1所述仲裁者模块根据预先配置的规则及本次呼叫相关信息进行仲裁；

C2所述仲裁者模块修改本次呼叫产生的消息，并转发给根据仲裁结果决定的处理本次业务的应用服务器；

C3所述仲裁者模块修改所述业务的状态，并移交控制权给所述应用服务器。

此外在所述方法中，所述步骤C3进一步包含以下子步骤：

所述应用服务器根据所对应的业务的状态决定业务的动作，所述业务的状态包含悬挂、嵌套、中断、互斥，其中，

当两个交互业务的关系为嵌套且第一个业务嵌套在第二个业务中时，第一个业务处于嵌套状态并执行，第二个业务处于悬挂状态并暂停；

当两个交互业务的关系为中断且第一个业务中断第二个业务时，第一个业务处于中断状态并执行，第二个业务处于悬挂状态并暂停；

当两个交互业务的关系为互斥且第一个业务优先级高于第二个业务时，执行第一个业务，并终止第二个业务。

此外在所述方法中，还包含步骤：所述管理者模块预先给所述仲裁者模块配置所述规则，在呼叫过程中记录该呼叫的处理信息，并决定控制权在所述仲裁者模块及处理业务的应用服务器之间转交。

此外在所述方法中，所述管理者模块所管理的呼叫相关信息包含呼叫的处理过程、呼叫的业务拓扑结构、呼叫的注册业务信息、和呼叫的处理规则。

此外在所述方法中，所述步骤C中所述仲裁者通过执行预先配置的脚本，对本次呼叫产生的交互业务进行仲裁。

此外在所述方法中，所述步骤C中所述仲裁者在获得控制权后，执行脚本进行仲裁，先根据本次呼叫产生的消息和待仲裁业务，查找二维规则表，根据表项中规则条件与本次呼叫相关信息的匹配结果，执行仲裁。

此外在所述方法中，还包含以下步骤：所述管理者模块控制所述仲裁者模块的产生与消亡，使得所述仲裁者模块在与其相关的消息触发时产生、在与其相关的交互业务终止后消亡。

此外在所述方法中，在预先配置规则时包含以下步骤：

首先对所有业务进行分类管理，使得不同类业务之间不存在交互；

再对同一类业务进行特征分析，获得任意两个业务之间的交互关系；

根据交互关系配置规则。

通过比较可以发现，本发明的技术方案与现有技术的主要区别在于，通过设置service broker逻辑功能，处理AS之间的业务交互，屏蔽交互对AS产生的影响，保证AS的独立性，并实现多业务交互的管理功能；

在service broker中设置动态产生和消亡的仲裁者和全局管理者模块，仲裁者用于负责对应AS间的业务交互仲裁，管理者负责呼叫相关信息的维护，管理控制权的移交，并提供仲裁者查询信息，配置仲裁规则；

通过业务分类管理、特征分析、生成规则实现一种通用的预先配置规则的方法，解决多业务情况下的仲裁规则配置问题；

引入业务状态转移机制和业务交互模型，包括悬挂、嵌套、中断和互斥等状态，和基于这些状态所建立的解决多业务交互的实现机制；

通过预置的处理脚本和查表、规则匹配机制来简化仲裁的复杂逻辑，实现提高处理效率。

这种技术方案上的区别，带来了较为明显的有益效果，即结合IMS的特征，针对3GPP的应用业务架构，提出IMS域内service broker的一种实现方案，解决多业务间的交互和冲突，保持各个AS的独立性，多业务间的一致性和协调性。对service broker的逻辑功能给出了一种有效的实现机制，基于这种机制，使得service broker的业务逻辑处理有序化，规则化，解决复杂的多业务交互处理问题，为IMS的多业务应用提供了基本的解决方法；

其中通过仲裁者和管理者功能的划分简化了系统实现难度，通过业务状态转移机制的建模明确了交互问题解决方式，通过仲裁者的动态产生和消亡机制提高系统处理资源利用率，通过用脚本描述规则来简化系统逻辑结构、提高系统执行效率，通过规则生成的通用化方法提高业务能力交互管理系统的通用性和可扩展性。

附图说明

图1是本发明的业务交互能力管理系统的基本结构图；

图2是根据本发明的第一实施方式的业务交互能力管理系统的基本框架图；

图3是根据本发明的第三实施方式的嵌套业务交互处理流程图；

图4是根据本发明的第三实施方式的互斥业务交互处理流程图；

图5是根据本发明的第四实施方式的业务交互能力管理方法流程图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明作进一步地详细描述。

本发明结合IMS的特征，针对3GPP的应用业务架构，提出IMS域内service broker的一种实现方案，解决多业务间的交互和冲突，保持各个AS的独立性，多业务间的一致性和协调性。基于一种新定义的机制，使得servicebroker的业务逻辑处理有序化，规则化。

基于该问题的要求，为了使得AS独立，本发明通过设置专门处理业务交互问题的service broker层，由该层统一处理业务交互所引发的问题，屏蔽交互对单个AS的影响，使得业务交互或冲突问题对AS透明。图1是本发明的给出SCIM系统的基本构架。

在S-CSCF层与AS层之间存在service broker逻辑功能，而且任意两个AS之间的交互均经过service broker逻辑功能实现，由service broker对AS的操作完成AS业务交互或冲突问题的处理，保证AS独立性。

本发明的关键在于service broker逻辑功能的具体实现及其与其他网络功能实体的交互体制的建立。本发明设置至少一个仲裁者模块和一个管理者模块来实现service broker逻辑功能实体。其中任意一个仲裁者都是唯一对应于两个AS之间，即专门解决两个AS之间的交互问题，而管理者则作为全局问题的管理角色，记录呼叫全程处理信息，配置仲裁者具体规则，负责管理控制权转交给某一个仲裁者，由仲裁者去执行。

当消息一开始触发到service broker层，该层产生对应的仲裁者对其处理，仲裁者对消息的处理是先将其上报给管理者，得到控制权后进行仲裁，然后转发给AS，AS处理过程中产生的消息将由对应仲裁者处理，消息使得控制权转交给对应的仲裁者，该仲裁者查询管理者中各种信息进行处理，完成业务交互，并把控制权给新的AS，依次类推。

可见，核心步骤在于：通过发生消息的方式使得控制权在AS与仲裁者间转交，当发生业务交互时，仲裁者先与管理者交互，然后根据预先配置的规则进行仲裁，这时AS的状态被修改；另外，预先配置规则这一步非常关键，需要预先根据业务种类、相互关系设定这些仲裁规则，由仲裁者去执行。

为了保证业务链上的各个AS之间的独立性，不能出现前面的业务处理依赖于后面的业务处理的中间状态，或依赖于后面处理结果的影响。如果出现了上面这两种依赖性，都必须由service broker来处理，进行转换和屏蔽。因此，每出现一次悬挂/嵌套，或悬挂/中断，都必然要求service broker充当仲裁角色，从这一点来考虑，该业务链上和service broker的每一次交点都是一个仲裁，该链上假设有n个AS，则需要经过service broker达n+1次，即可能会产生n个仲裁。显然必须保证这n个仲裁之间是相互独立的(即不能互相感知)，同时可以确定，一个仲裁仅仅能够在属于自己范围内的两个AS之间进行仲裁。根据这一原理，本发明的第一实施例给出了service broker内部结构解决方案。

图2是根据本发明的第一实施例的业务交互能力管理系统框架图。首先包含多个AS服务器10-1，10-2等，然后是service broker逻辑功能20，还有S-CSCF功能实体30。其中service broker逻辑功能20包括多个仲裁者21-1、21-2、21-3等和管理者22。

仲裁者模块用于在受本次呼叫产生的消息触发并获得控制权后，根据预先配置的规则及与管理者模块22交互得到的本次呼叫相关信息，对本次呼叫产生的消息进行处理，并对本次呼叫产生的交互业务进行仲裁。

而管理者模块22则充当本地数据库的角色，用于管理所有呼叫相关信息，同时也充当控制模块的角色，管理控制权的转交，通过与所有仲裁者模块交互以更新本次呼叫相关信息并向仲裁者提供查询。

其中在一次端对端呼叫过程中，用户A发起呼叫经过S-CSCF功能30路由到AS服务器10-1，这时必须先经过service broker功能20，在servicebroker功能20中产生第一个仲裁者21-1来处理这个消息，对于呼入消息不存在多种业务交互，因此直接转发给AS服务器10-1，但同时需要上报给管理者22，由管理者22记录该呼叫的相关信息，并跟踪记录该呼叫之后的处理过程。呼叫经由AS服务器10-1服务后产生消息，引起业务交互，这时触发发生业务交互的两个业务间的仲裁者，由仲裁者对消息进行处理，仲裁者首先通知管理者22，获得该呼叫的相关信息，再根据预先配置的仲裁规则，假定仲裁结果为AS服务器10-2进行处理，对消息进行修改后转发给AS服务器10-2，然后按仲裁结果修改AS服务器10-1和10-2的状态，比如被中断的AS服务器10-1改为悬挂状态，中断AS服务器10-2则开始运行业务。如此反复进行，直到呼叫处理结束。

归纳上述工作流程的几个基本步骤如下：首先由本次呼叫产生的消息触发，对应仲裁者模块获得控制权；该仲裁者模块与管理者模块交互，得到本次呼叫相关信息；然后，该仲裁者模块根据预先配置的规则及本次呼叫相关信息，对本次呼叫产生的消息进行处理，并对本次呼叫产生的交互业务进行仲裁；同时，管理者模块更新本次呼叫相关信息。这个流程就是本发明的业务交互能力管理方法的一个基本实施方式。

本发明的第二实施例在第一实施例的基础上，给出更详细的解决方案。在本实施例中，仲裁者对本次呼叫产生的交互业务进行仲裁时，修改本次呼叫产生的消息，并转发给目的网元，然后通过修改业务的状态实现交互，之后移交控制权给对应的AS，AS根据业务状态执行。这里仲裁者是通过修改业务状态来通知AS如何动作，以避免冲突或者顺利完成交互，从根本上实现AS对业务交互的透明。

业务交互及业务状态机制的建立需要预先通过业务分析实现，本实施例基于IMS当前各种业务交互情况，给出一种通用的业务分析、模型建立方法，该方法分为业务分类管理、业务特征分析、仲裁规则生成三步实现。在给仲裁者预先配置规则时，首先对所有业务进行分类管理，使得不同类业务之间不存在交互；再对同一类业务进行特征分析，获得任意两个业务之间的交互关系；根据交互关系配置规则。

如何制定service broker的交互处理规则，是面临的一个关键的问题，这一问题的解决虽然不影响本发明的基本构架，但是本发明第一实施例中基本构架运行的关键。本发明第二实施例给出了一般通用的步骤来分析制定交互仲裁规则。

分类管理就是将纷杂的多种多样的业务进行分类，保证不同类别之间的交互尽量单一化和简单化；特征分析就是在已经分好类的某一个类中间，对多个业务可能出现的交互点进行分析，定义和描述，对不同类间，不同群间也进行同样的分析；生成规则就是依据特征分析的结果生成最后的规则，表明在什么条件下，采取什么仲裁措施。

分类管理就是将关联性较强的业务归结为一个类中，没有关联性和关联性单一的归结为不同类中，一般有如下分类：

电话业务中呼叫相关类业务或补充业务：包括呼叫建立，完成类补充业务CW/CH/MPTY/3 part，群类Centrex群或CUG，前转类补充业务，号码显示类，呼叫闭锁限制类(包括长话权，黑白名单以及各种闭锁)；

电话业务中非呼叫相关类补充业务：包括激活去激活类，登记去登记，注册去注册；

消息类业务：包括UC，SMS，MMS，Chat，IM；

使能类业务，一般指XDMS/Presence；

根据上面的分类，可以保证不同类之间的交互是一种确定的单一化关系，同种类业务的交互则依赖于下面的特征分析。基于已经完成的分类，可以引入群的概念，将有共同特征的多个类归结为一个更抽象的群。

在得到业务分类之后，对于每一类业务需要继续进行特征分析，这个过程是最复杂也是最关键的过程，service broker的核心就是保证各个AS业务的相对独立，所有的交互和冲突都只能由service broker自身来完成，对AS/S-CSCF都是透明的。该步骤需要给出业务各种交互关系的定义以及交互处理原则。

本发明第二实施例根据现有业务的各种交互关系归纳如下业务状态转移模型：业务的状态包含悬挂、嵌套、中断、互斥，其中，当两个交互业务的关系为嵌套且第一个业务嵌套在第二个业务中时，第一个业务处于嵌套状态并执行，第二个业务处于悬挂状态并暂停；当两个交互业务的关系为中断且第一个业务中断第二个业务时，第一个业务处于中断状态并执行，第二个业务处于悬挂状态并暂停；当两个交互业务的关系为互斥且第一个业务优先级高于第二个业务时，执行第一个业务，并终止第二个业务。

可见在本发明第二实施例中，业务交互和冲突被抽象为一种应用业务的前提条件被另外一种应用业务所破坏，基于这种抽象定义上述四种状态，对于各种业务交互关系及其状态的进一步描述如下：

嵌套：当一种业务A处理过程中间又触发了另外一种业务B，则构成嵌套，当且仅当后面的嵌套B处理完毕，才继续处理本层业务A，嵌套可以允许多层次的嵌套，可以想到，嵌套是构成业务交互的根本；

中断：和嵌套类似，但中断不允许被再次嵌套或中断，即一次中断是排它性和独占性的，当中断完全处理完毕，才回到原来的位置继续处理，这种情况也可以看成是嵌套的一个最简特例。一般而言，纯事件的触发，消息类业务都可以定义为中断；

互斥：前面分析的结果，和本次的判决具有互斥性，这种情况最为复杂，理论上要根据具体的业务和场景来综合判断，为了简单起见，我们可以采用先得出的结论优先，类似于顺序优先，也有采用覆盖(override)，即最后结果优先的，到底采用哪种方法依赖于不同的实现。典型的如前转两次的彩铃业务；

悬挂：悬挂是相对而言的，当出现嵌套/中断时，被嵌套被中断的业务就处于悬挂状态，其必和嵌套/中断相关联产生。悬挂并不是指一旦被悬挂后必须等待其中的嵌套处理完毕，而是指该悬挂可能被某条消息去悬挂后，跃迁到一个新状态，再次进入另一种状态的悬挂。

由此service broker的业务交互可以分解为嵌套/中断，完全冲突(互斥)，悬挂等几种类型，上面4种机制是完全对等的，不存在谁优先的问题，任何两种业务交互必然各自产生上面4种中的一种，否则这两种业务被认为不存在交互和冲突，此时service broker仅仅起到一个纯粹的代理(Proxy)功能，由于Proxy角色已经在相关协议规范中有明确的定义，即主要完成消息转发等功能。

给出业务状态转移机制和仲裁规则配置方案后，整个系统仅需要管理者功能实现后即可完成预期的目的。本实施例中，管理者模块用于给仲裁者模块配置规则、记录呼叫处理信息，并决定控制权在仲裁者模块及应用服务器之间转交，使得AS正常服务，并通过仲裁者有序仲裁后顺利完成交互。

这里提出两个新的术语：相关链型集和控制权转移，它们都是管理者模块的概念。当每一次消息到达，仲裁者都会向管理者询问是否具有控制权，并得到当前的相关链型集的拓扑视图，以匹配对应的规则并触发相应的过程。实际上，这里的管理者就是一个本地数据库，保存有当前处理的消息状态，以及各种视图数据，如控制权和拓扑等。而管理者模块需要管理的呼叫相关信息包含呼叫的处理过程、呼叫的业务拓扑结构、呼叫的注册业务信息、呼叫的处理规则。这些呼叫相关信息必须在过程中动态更新，以提供仲裁者做出正确仲裁。

所谓相关链型集，是指将各个AS在整条链中流畅地链接起来，保证让各个AS完全独立起来，而看不到自己的前后有其它业务在并行触发。相关链型集的拓扑必须有一个管理者，因此service broker必须有一种管理机制，记录并维护n+1个相关链型触发，也称为相关链型集。

所谓控制权转移，是指控制权先从S-CSCF转移到service broker，再转到AS1，再到service broker，再到AS2，如此循环，这个机制保证避免多个AS同时处理而导致错误，一个给定的时刻只有一个AS在处理。

至此，本实施例中的系统已经能够实现消息触发仲裁、仲裁与管理交互、仲裁控制业务状态、AS根据业务状态执行。此外，本实施例为了提高设计效率和执行效率，还用设计脚本来执行以实现仲裁功能。规则配置的实现即由service broker产生一个运行脚本(script)，仲裁者便于按照该脚本来执行。

用脚本实现规则能够方便系统的实现和扩展，但脚本的设计将影响执行效率。本实施例通过多维表格查询和规则匹配的方法实现脚本。仲裁者在获得控制权后，执行脚本进行仲裁，先根据本次呼叫产生的消息和待仲裁业务，查找二维规则表，根据表项中规则条件与本次呼叫相关信息匹配结果，执行仲裁。

在本发明中，每一个仲裁者都是一个三维的概念，第一个维度是是否具有处理控制权，第二个维度是相关链型集的拓扑视图(包括状态，前次仲裁结果模型)，收到的消息和方法，第三个维度是被仲裁的业务对象的触发条件和规则，这3个维度组合起来形成一次仲裁的最终结果。

首先建立一张二维表格，这个表的内容是仲裁规则，而表格由所有消息和业务分别索引，对应某一种业务，当发生某种消息或事件实，查表得到对应表项给出了被触发的可能性和优先级等信息，供仲裁者参考执行。

另外，引入规则模型(Rule module)用来标识什么样的情况下执行什么样的操作，这个规则模型包括触发的条件规则和期望的处理方式，最终以XML等语言的形式表示出来，被service broker的仲裁者所使用，以达到解决业务交互的控制处理。这个规则模型非常类似于3GPP的iFC，即满足一定的条件，触发相应的过程。

由此可见，根据规则进行仲裁的方法流程归纳如下：当Server broker收到任何消息，首先向管理者询问控制权，若没有控制权，则只能缓存该消息或简单抛弃；

若仲裁者获得控制权，则向管理者询问拓扑视图，获取仲裁对象，各个对象当前处理的消息状态，前次仲裁结果模型，和收到的消息和方法进行匹配，若不匹配则进入一般的SIP错误处理；

若匹配则根据收到的消息或方法中携带的关键信息和特征，来查询表格，匹配表项中的触发条件和规则，若不能匹配，则进入一般SIP错误处理，若匹配则获得最终的处理结果，并依据该结果进行消息处理和控制过程。

最后，还需要指出一点，本发明第二实施例还采用了仲裁者模块动态产生与消亡机制以节省处理器资源。如前所述，每两个AS之间需要存在一个仲裁者模块，然后AS众多必然使得仲裁者模块太多而无法高效实现，但注意到每次呼叫时仅仅是所涉及到的AS所对应的几个仲裁者模块在起作用，大多数仲裁者模块不需要执行功能。

因此本发明用动态产生和消亡的方式。由管理者模块控制仲裁者模块的产生与消亡，仲裁者模块在与其相关的消息触发时产生，在与其相关的交互业务终止后消亡。比如呼叫触发时，产生对应的仲裁者，而当呼叫所涉及的业务AS中某一种业务终止使得该AS不起作用，这时与该AS相关的所有仲裁功能都失去意义，便可以消亡。这种方式使得系统处理器可以动态调用，大大节约处理器资源，提高系统效率。

本发明第三实施例首先根据具体应用情况给出几种交互模式的处理流程。定义ServiceBroker针对不同关系需要进行的处理是一个复杂的过程，根据上文分析，归纳为下面几种：

悬挂/嵌套：这种关系的情况下，仲裁者首先保存有前后两个UA(假定为A/B)呼叫处理的历史状态，当从B收到后续的响应消息时，仲裁者将从管理者数据库查询相关控制信息和处理规则，并依据预置的脚本决定处理步骤，当匹配到某条规则时，将该规则定义的处理结果发给A，A根据仲裁者修改后的消息进行处理，继而完成A的业务逻辑。显然这时控制权已经由B转移到A，当A处理完毕后，放弃控制权，此时A已经从一种状态的悬挂进入到另一种状态的悬挂。嵌套业务的处理流程如图3所示。

悬挂/中断：在这种关系下，基本和悬挂/嵌套类似，不同之处在于A不会放弃控制权，而是继续进行自身的后续处理。

互斥：这种关系的处理比较简单，当仲裁者已经完成仲裁后，相互排斥的业务不会同时出现在相关链型集中。这时如果需要继续选定的业务处理，则被排斥的业务原有逻辑必须被先行终止。互斥业务的处理流程如图4所示。

本发明的第四实施例是一种典型应用场景下的各个步骤和环节的具体实现方案。最简单的应用就是通话，比如移动发端呼叫终端时需要触发呼叫等待(Call Waiting，简称“CW”)，呼叫到达时触发呼叫显示(Call screening)，而无应答时触发前转(forward)、语音邮箱(VoiceMail)等业务，这些业务都是和呼叫相关的呼叫建立业务，因此都归类为电话业务中呼叫相关类业务或补充业务，相互之间存在交互关系。

对这一类业务进行特征分析：

CW就是在传统意义上的呼叫等待；

Call Screening是指在入呼到达时，主叫用户信息必须先行被记录并显示给被叫用户，被叫据此主叫信息来决定不同的操作，通过按下不同的功能选择键决定是否接受或拒绝该次呼叫，如何选择不同的功能键将通过语音提示来完成；

VoiceMail是指语音邮箱功能，在用户无应答/忙时，可以前转到语音邮箱。

通过分析，显然语音邮箱和CW/CallScreening出现了冲突，若该次呼叫到达语音邮箱，则到目标用户的呼叫建立必然是失败的，从这个意义上分析，结果要么是CW/CallScreening呼叫建立成功，要么是建立失败而前转到语音邮箱；

其次，CW/CallScreening，这两个业务都是在Invite时触发，但由于CallScreening为呼叫建立之前的预处理，因此在时间上应该先处理，当CallScreening处理完毕，则可以继续正常的被叫流程，此后才触发被叫的CW流程，因此顺序为MT procedure-CallScreening success-CW procedure；

另外，语音邮箱是在4XX时触发的，触发时机不同于CW/CallScreening。

从上面的分析可以看出，CallScreening和CW形成悬挂/嵌套关系；CallSereening/CW和VoiceMail形成互斥关系。

可以预见，在呼叫过程中将产生以下业务交互情形：

当被叫的service broker在收到终端Invite时，会触发CallScreening以及CW，CallScreening具有高优先级，因此触发CallScreening；

当被叫的service broker在收到终端Invite时，会触发CallScreening以及CW，高优先级CallScreening已经触发而激活，因此触发具有次优先级的CW；

当被叫的service broker在收到4XX时，企图触发前转语音邮箱，由于语音邮箱和CallScreening/CW是互斥的，因此要想触发语音邮箱，必须先将CallScreening/CW终结掉，并同时存取4XX事件；

最后触发语音邮箱，完成放音或留言；

针对这一情况，接着需要建立仲裁规则，一般而言，触发业务的顺序依赖于触发点所在呼叫信令的顺序，如CW肯定依赖于MT的Invite，因此必然在Invite的时机触发，而无应答前转肯定是在4XX时触发等。但同样依赖于Invite的多个业务的顺序就只能依据具体的业务来指定了，目前没有一定的规律，依据不同的实现而不同。针对这种情况，有必要引入优先级，同种条件下，要求先触发的业务具有高优先级，依据不同的优先级，可以很好地解决这个问题。若高优先级已经触发，也需要在管理者中形成记录，便于其它仲裁者查询。由此需要建立如下所示的二维表格描述这些规则。

	Call Screening	CW	Callfowarding	………
					Invite(MT)	可能被触发，第一优先级	可能被触发，第二优先级	none
…
					…
4XX	none	none	可能被触发，第一优先级
					BYE

上表中仅给出涉及到的业务，其它业务的触发处理优先级顺序没有给出。根据定义完毕的该种表格，可以得出，当Invite到达时，最先触发CallScreening，然后触发CW，依此类推。

对于上述表项的内容，还需要给出规则条件，生成脚本如下，其和特征分析一一对应：

Rule3a获得控制权后，收到终端Invite，拓扑图无，前次仲裁结果无，且被叫签约数据为CallScreening/CW，则期望的处理为先处理高优级CallScreening；

Rule3b获得控制权后，收到终端Invite，拓扑为MT→CallScreening，且被叫签约数据为CallScreening/CW，则期望的处理为处理第二优先级CW；

Rule3c获得控制权后，收到4XX消息，拓扑为MT→CallScreening→CW，且被叫签约了CallScreening/CW/VoiceMail，4XX原因为无应答，则期望的处理为存取4XX消息和事件，反向释放CW/CallScreening；

Rule3d获得控制权后，如果释放完毕，拓扑已经变为VoiceMail，4XX事件存在还未处理，且被叫签约了VoiceMail，则期望的处理为前转到语音邮箱。

完成规则配置后，先描述一个动态工作流程：

假设主叫用户为Jane，被叫B签约有CW/CallScreening/VoiceMail等业务。考虑一个有代表性的应用场景，Jane发起一个呼叫到B，B无应答后前转到语音邮箱的情况。为了简单清晰起见，只考虑B的service broker逻辑的处理。

如图5所示，处理流程如下：

第一次收到Invite，则必然匹配到Rule3a，因此CallScreening被激活，CallScreening完成相应操作，记录主叫Jane的名字，然后将Invite再次发给service broker，并向管理者告知仲裁者1已经建立MT→CallScreening的链型拓扑，触发消息状态为Invite。

service broker再次收到Invite时，则必然匹配到Rule3b，因此CW被激活，CW完成相应操作，然后将Invite再次发给service broker，这时servicebroker仅仅起到Proxy的角色，将Invite发给用户B，并向管理者告知仲裁者2建立了CallScreening→CW的链型拓扑，触发消息为Invite。至此总的拓扑为MT→CallScreening→CW。

用户B返回180，定时器超时后返回无应答4XX，service broker检测到无应答事件，匹配到Rule3c，转而存取4XX事件到管理者，并反向释放CW/CallScreening。注意此时仍然只有仲裁者1和仲裁者2存在。

service broker完成正常的释放过程，因此向管理者删除拓扑MT→CallScreening→CW，同时发现还有4XX事件没有处理，因此匹配到Rule3d，则触发语音邮箱，并告知管理者仲裁者3已经建立MT→VoiceMail的拓扑，触发事件为4XX。

熟悉本领域的技术人员可以理解，上述各个实施例给出的具体实现方案是为了帮助理解而具体说明，在实际应用中可以有其它可行的实现方式，这些情况比如：

在对多种业务进行分类的情况下，可以根据其它法则进行分类，或者抽象为群的概念并引入群管理，将有相同属性的分类再次归结为一个更抽象的更高层次的群，使管理者的功能更加具体化和层次化，从而提供一种更为强化的管理者功能；

对于两种业务之间的交互类型的抽象可以更加具体，如对于中断可以细分为无条件中断和有条件中断，对于嵌套也可以细分为触发新业务的嵌套和触发新会话的嵌套；

在配置规则时，不同群之间Rule module的定义、不同种类业务之间Rulemodule的定义、同种类内不同业务的Rule module的定义，都可以根据实际情况实现；

在可能出现一对多业务的情况下(如Forking，Group)，相关链型集将可以出现多条子链并存的情况，需要增强管理功能，实现多条子链的管理关联性；

另外，经过分类管理、特征分析、生成脚本之后，还可以根据不同的应用场景和本地策略，对最终生成的脚本进行一定的静态配置，以适应不同运营商的需要；

类似上述各种情况，采用其它可行方式实现发明目的，均不影响本发明的实质和范围。

虽然通过参照本发明的某些优选实施方式，已经对本发明进行了图示和描述，但本领域的普通技术人员应该明白，可以在形式上和细节上对其作各种改变，而不偏离本发明的精神和范围。

Claims (17)

1.一种通信网络中业务能力交互管理系统，其特征在于，包含一个管理者模块和至少一个仲裁者模块，

所述仲裁者模块用于在受本次呼叫产生的消息触发并获得控制权后，根据预先配置的规则和通过与所述管理者模块交互得到的本次呼叫相关信息，对本次呼叫产生的消息进行处理，并对本次呼叫产生的交互业务进行仲裁；

所述管理者模块用于管理所有呼叫相关信息，管理控制权的转交，通过与所述仲裁者模块交互以更新本次呼叫相关信息并向所述仲裁者提供查询。

2.根据权利要求1所述的通信网络中业务能力交互管理系统，其特征在于，所述仲裁者模块对本次呼叫产生的交互业务进行仲裁时，修改本次呼叫产生的消息，并转发给根据仲裁结果决定的处理本次业务的应用服务器，然后修改所述业务的状态，并移交控制权给所述应用服务器。

3.根据权利要求2所述的通信网络中业务能力交互管理系统，其特征在于，所述应用服务器根据所对应的业务的状态决定业务的动作，所述业务的状态包含悬挂、嵌套、中断、互斥，其中，

当两个交互业务的关系为嵌套且第一个业务嵌套在第二个业务中时，第一个业务处于嵌套状态并执行，第二个业务处于悬挂状态并暂停；

当两个交互业务的关系为中断且第一个业务中断第二个业务时，第一个业务处于中断状态并执行，第二个业务处于悬挂状态并暂停；

当两个交互业务的关系为互斥且第一个业务优先级高于第二个业务时，执行第一个业务，并终止第二个业务。

4.根据权利要求1所述的通信网络中业务能力交互管理系统，其特征在于，所述管理者模块还用于给所述仲裁者模块配置所述规则、记录呼叫处理信息，并决定控制权在所述仲裁者模块及处理业务的应用服务器之间转交。

5.根据权利要求4所述的通信网络中业务能力交互管理系统，其特征在于，所述管理者模块所管理的呼叫相关信息包含呼叫的处理过程、呼叫的业务拓扑结构、呼叫的注册业务信息和呼叫的处理规则。

6.根据权利要求1所述的通信网络中业务能力交互管理系统，其特征在于，所述仲裁者通过执行预先配置的脚本，对本次呼叫产生的交互业务进行仲裁。

7.根据权利要求6所述的通信网络中业务能力交互管理系统，其特征在于，所述仲裁者在获得控制权后，执行脚本进行仲裁，先根据本次呼叫产生的消息和待仲裁业务，查找二维规则表，根据表项中规则条件与本次呼叫相关信息的匹配结果，执行仲裁。

8.根据权利要求1至7中任一项所述的通信网络中业务能力交互管理系统，其特征在于，所述管理者模块控制所述仲裁者模块的产生与消亡，所述仲裁者模块在与其相关的消息触发时产生，在与其相关的交互业务终止后消亡。

9.一种通信网络中业务能力交互管理方法，其特征在于，包含步骤：

A.仲裁者模块受本次呼叫产生的消息触发，获得控制权；

B.该仲裁者模块与管理者模块交互，得到本次呼叫相关信息；

C.该仲裁者模块根据预先配置的规则及本次呼叫相关信息，对本次呼叫产生的消息进行处理，并对本次呼叫产生的交互业务进行仲裁；

D.所述管理者模块更新本次呼叫相关信息。

10.根据权利要求9所述的通信网络中业务能力交互管理方法，其特征在于，所述步骤C包含以下子步骤：

C1.所述仲裁者模块根据预先配置的规则及本次呼叫相关信息进行仲裁；

C2.所述仲裁者模块修改本次呼叫产生的消息，并转发给根据仲裁结果决定的处理本次业务的应用服务器；

C3.所述仲裁者模块修改所述业务的状态，并移交控制权给所述应用服务器。

11.根据权利要求10所述的通信网络中业务能力交互管理方法，其特征在于，所述步骤C3进一步包含以下子步骤：

所述应用服务器根据所对应的业务的状态决定业务的动作，所述业务的状态包含悬挂、嵌套、中断、互斥，其中，

当两个交互业务的关系为嵌套且第一个业务嵌套在第二个业务中时，第一个业务处于嵌套状态并执行，第二个业务处于悬挂状态并暂停；

当两个交互业务的关系为中断且第一个业务中断第二个业务时，第一个业务处于中断状态并执行，第二个业务处于悬挂状态并暂停；

当两个交互业务的关系为互斥且第一个业务优先级高于第二个业务时，执行第一个业务，并终止第二个业务。

12.根据权利要求9所述的通信网络中业务能力交互管理方法，其特征在于，还包含步骤：所述管理者模块预先给所述仲裁者模块配置所述规则，在呼叫过程中记录该呼叫的处理信息，并决定控制权在所述仲裁者模块及处理业务的应用服务器之间转交。

13.根据权利要求9所述的通信网络中业务能力交互管理方法，其特征在于，所述管理者模块所管理的呼叫相关信息包含呼叫的处理过程、呼叫的业务拓扑结构、呼叫的注册业务信息和呼叫的处理规则。

14.根据权利要求9所述的通信网络中业务能力交互管理方法，其特征在于，所述步骤C中所述仲裁者通过执行预先配置的脚本，对本次呼叫产生的交互业务进行仲裁。

15.根据权利要求9所述的通信网络中业务能力交互管理方法，其特征在于，所述步骤C中所述仲裁者在获得控制权后，执行脚本进行仲裁，先根据本次呼叫产生的消息和待仲裁业务，查找二维规则表，根据表项中规则条件与本次呼叫相关信息的匹配结果，执行仲裁。

16.根据权利要求9所述的通信网络中业务能力交互管理方法，其特征在于，还包含以下步骤：所述管理者模块控制所述仲裁者模块的产生与消亡，使得所述仲裁者模块在与其相关的消息触发时产生、在与其相关的交互业务终止后消亡。

17.根据权利要求9至16中任意一项所述的通信网络中业务能力交互管理方法，其特征在于，在预先配置规则时包含以下步骤：

首先对所有业务进行分类管理，使得不同类业务之间不存在交互；

再对同一类业务进行特征分析，获得任意两个业务之间的交互关系；

根据交互关系配置规则。

Images