摘要 针对IMS中业务交互管理问题，本文首先介绍和分析了IMS中现有基于过滤规则的业务触发机制和存在问题，然后针对3GPP标准中新增的SCIM实体，介绍了相关研究现状和改进方式，最后分析了现有业务交互管理中存在的问题并提出下一步发展方向。
1、引言
IMS（IP多媒体子系统）是第三代移动网络的核心网技术。它采用IP传送技术，同时业务层面在兼容目前已有的业务的同时开放了网络能力接口，为业务开发商提供了方便、快捷、经济地提供业务的途径。这种开放的全IP的架构使得IMS上的业务可以变得丰富多彩，同时也使业务交互问题变得更为明显。
业务交互指的两个或者多个业务在同时执行的过程中相互影响甚至干扰。根据是否违反用户期望，业务交互分为业务协作和业务冲突。业务协作是用户期望的交互行为，例如将已有的多个业务或业务能力组合成为一个新业务；业务冲突是用户未预期的交互行为。一个业务冲突的例子是“主叫呼出限制（OCS）”和“被叫呼叫转移（CFU）”：假设用户A订购了OCS业务并限制拨打用户B，而用户C订购了CFU业务并设置前转地址为B，当用户A呼叫用户C时，该呼叫被CFU业务转移到用户B，而用户B在OCS限制的范围内，这便产生了违背用户意愿的业务冲突，原本用户A与B的通话应该被OCS业务限制的，而现在用户A却与B进行通话。
业务协作有助于方便、快速、经济地提供新业务，可以提高用户体验，而业务冲突则会影响用户体验，甚至影响系统稳定性和安全性。由于业务交互问题的重要性，业界给予了长期的关注。在IMS发展部署过程中，这也是亟待解决的重要问题。3GPP定义了SCIM/Service Broker（业务能力交互管理器/业务代理）实体来处理IMS中的业务交互问题。目前3GPP对该问题正处于研究之中，相关标准尚未成熟。
2、IMS中的触发机制和存在的问题
业务交互问题的已有研究和统计分类表明，多数业务交互问题都与业务触发机制相关。例如，共享触发类的业务冲突就是在同一事件点触发了多个业务从而产生冲突。在什么情况下触发业务，选择哪个业务来执行，就是触发机制应当解决的问题，如果不能恰当地解决此问题就会导致冲突。
3GPP的标准中，业务触发的方式是S-CSCF（服务呼叫会话控制功能）按照iFC（初始过滤准则）的优先级依次匹配每一条iFC，匹配成功后触发相应的应用服务器（AS）来执行业务。AS可以对请求消息作一定的处理后再返回给S-CSCF，S-CSCF接着匹配下一优先级的iFC，触发相关的AS，依次进行直到匹配完所有的iFC。iFC中规定了多个触发点（SPT），在匹配过程中S-CSCF检查当前会话的情况是否满足触发点的要求。目前规定有5类触发点，分别是Request URI、SIP方法、SIP Header、会话描述、会话情形（Originating、Terminating Terminating_Unregistered）。
为了使S-CSCF按正确的顺序处理不同的FC，每个FC都必须分配一个优先级，并且在提供给用户的FC中，不应该有一个优先级对应一个以上的FC。如果S-CSCF不能联系到AS，那么S-CSCF应该为这个触发使用默认的处理方式。默认处理可以是：如果在列表中匹配了一个低优先级触发项，则继续检验，放弃与列表中低优先级匹配的校验，并释放这个对话。这种基于优先级限制每个优先级只对应一个FC的触发方式，可以在一定程度上解决共享触发类的业务冲突问题。
这种iFC触发机制的功能较为薄弱，它按照静态的优先级依次触发各个AS，因此难以处理多个业务交互的情况。具体来说，它存在的不足之处如下。
●静态性：iFC机制在初始请求到来的时候，按静态配置好的顺序触发相关AS，而无法根据业务的触发情况、会话的进展动态地触发AS。
●使用范围有限：只能依据目前的5类触发点来判断是否触发一个业务，然而除此之外尚有许多因素可作为触发点，例如：终端能力、用户偏好、时间因素、前一个业务执行情况等。
●表达能力有限：iFC只能按照规定的优先级顺序触发AS，实现简单的业务组合，而对于实现复杂的业务组合则无能为力，例如它无法将Presence业务和补充业务有效结合起来，根据用户不同Presence状态调用不同的补充业务。
●缺乏在线规避业务冲突的手段：iFC简单的顺序触发方式没有考虑AS之间的冲突问题，在这种情况下，相互冲突的业务可以在同一次会话中触发，影响用户体验。
3、SCIM研究和应用现状
为了有效控制和处理IMS中存在的业务交互问题，3GPP在IMS体系中引入一个新的网元——SCIM来专门负责协调业务运行，有时又称为Service Broker。SCIM最早出现在TS 23.218规范。在规范中，SCIM作为一种特殊的AS或者作为AS中的特殊功能实体，但是除了此概念以外，缺乏更进一步的定义以及关于SCIM的功能结构和实现方式的说明。
由于业务交互问题本身也较为复杂，业界缺乏对SCIM的统一认识和理解，所以不同厂商和研究人员从不同的角度对SCIM提出了自己的理解，其中以Michael Palmeter观点较有代表性，他把SCIM分为以下5类。
●AS Internal Function：SCIM作为AS内部的功能，作为request dispatcher存在。SCIM作为SIP AS的对外访问入口，根据收到的SIP请求有选择地调用各个业务。这种机制与AS的实现方式相关，是私有的，大部分SIP应用服务器都会提供类似的功能。
●SIP Broker：主要用于在外部管理SIP应用服务器之间的交互，可能有复杂的路由和排序规则引擎，其功能类似于S-CSCF的业务触发功能。
●Service Broker：解决业务能力的交互问题，业务能力需要使用WSDL和SOAP抽象并开放出来，SCIM将业务之间的交互看作是业务流程组合。
●Legacy/NGN：解决SIP和传统信令系统之间的交互。传统系统接口之间的区别很大，业务实现基于网络设备商的私有平台，因此这种SCIM估计不会是一种通用的解决方案，这种SCIM除了触发和路由机制外还需要有协议的映射机制。
●Service-Type Optimized：针对一种特定的服务类型而不是一组特定的实现技术进行了优化的SCIM。SCIM负责把特定的服务类型和一系列与其相关的服务组件集成，从而提供可定制的服务，例如，“电话”SCIM将与一些和电话相关的组件集成，这些组件支持媒体类型协商，用于电话的媒体服务器的控制、呼叫转移、呼叫等待、呼叫保留等标准过程。“电话”SCIM可以用来专门提供和电话业务相关的业务组合能力。
3GPP组织对SCIM的功能和控制流程进行了进一步研究，在TR 23.810中对Service Broker（即SCIM）的功能需求以及部分交互流程的控制方式和改进方式提出了建议。
3.1 Service Broker的功能需求
从总体上说，Service Broker提供一个可管理、可控制的手段让多个业务按照用户预想的方式执行。它掌握用户的业务订购情况，明确这些业务该按照何种顺序被触发，并且能够对存在冲突的业务进行协调。
对于Service Broker功能上的需求目前达成共识的主要有以下几点：
●尽可能减小因Service Broker的引入而对IMS核心网造成的影响；
●Service Broker必须采用灵活的架构以便能够应付新业务之间的交互问题；
●支持业务交互，即业务组合以及避免业务冲突；
●Service Broker应能够管理IMS应用与非IMS应用之间的交互；
●支持传统智能网与IMS业务的交互；
●支持不同接入方式的业务之间的交互，如UMTS、WiMAX、WLAN；
●支持SIP与非SIP业务之间交互；
●支持不同业务提供商的业务之间的交互；
●支持由用户配置、控制业务交互的方式。
3.2 Service Broker实现方式
TR 23.810提出了Service Broker的3种实现方式，分别是集中控制、分布式控制、混合式控制（如图1～3所示）。
图1 集中控制
集中控制方式由一个Service Broker来协调控制所有业务之间的交互，S-CSCF把Service Broker视为AS，通过ISC接口与惟一的Service Broker联系，Service Broker与AS之间的接口仍然是ISC接口，这种方式容易实现，但是Service Broker容易成为网络中的瓶颈。
图2 分布式控制
分布式控制方式为每一个AS都配置一个Service Broker，S-CSCF把每个Service Broker都视作AS，通过ISC接口与其交互。S-CSCF将请求触发给Service Broker，AS执行完后，Service Broker可以向S-CSCF发送sFC（subsequent filter criteria）以指示S-CSCF该如何触发接下来的业务，这样Service Broker可以根据冲突关系，动态地将后续业务排除出业务链，这种方式可以解决集中式方式的瓶颈问题，但是实现较为复杂，控制流程也较难设计。
混合式控制结合了上述两种方式，即有的Service Broker管理多个AS之间的业务交互，而有的Service Broker只和一个AS交互。在这种模式下，Service Broker不但要管理由它控制的AS之间的业务交互，还要管理属于不同Service Broker的AS之间的业务交互。图3（a）、（b）是两种可能的实现方式。
图3 混合控制
3.3 交互流程改进
影响SCIM实际应用的重要原因之一是SCIM的处理流程并不规范和统一，这不仅使SCIM对于业务交互的处理范围、处理方式都“无章可循”，而且SCIM与网络中其他实体之间也难以互通。TR 23.810中对部分实际遇到的交互问题提出了改进意见，这其中一部分改进可以由SCIM来完成，另一部分可以脱离SCIM，直接改进现网中的设备。
3.3.1 请求URI被修改的情况
SIP请求中的请求URI实际承担着两种角色：一是代表被服务的对象，被叫侧S-CSCF根据请求URI中所指示的共有用户标识进行iFC触发；二是代表着会话的目的地址，S-CSCF根据请求URI所指示的共有用户标识来进行路由，然而在业务触发阶段，某个AS可能改变了请求消息中的请求URI，结果S-CSCF将消息发往新的目的地，这导致后续本该被触发的AS无法被正常触发。因此，TR 23.810建议将请求URI所承担的这两种角色分离，S-CSCF根据当前服务URI进行业务触发，针对目的地URI进行呼叫路由。
3.3.2 对冲突业务划分等价类
在一次会话中触发的业务之间可能存在着冲突，通过在iFC中引入指示业务之间冲突关系的信息，可以避免互相冲突的业务被引入到同一个会话中。实现方法是将所有的iFC按照所触发的业务间的相容关系划分为若干个等价类，每条iFC中有专门的字段指示该iFC所属的等价类，等价类之间可能存在冲突。S-CSCF在判断是否触发某条iFC之前，需要断定是否有与该iFC所处等价类相冲突的某条iFC已经被执行，若已执行，则S-CSCF不能触发目前的iFC。
此外，S-CSCF必须能够判断一个业务的触发以及执行情况，以便确定冲突的业务是否已经执行。如果一个业务的iFC没有被匹配，或者iFC匹配了，但是AS返回一个错误响应或者没有返回响应，在这种情况下，S-CSCF视该业务执行失败。另外，即使S-CSCF触发了某个AS，并且AS也将请求消息返回给S-CSCF，也不能表明AS执行了该业务。因为AS是否执行还可能取决于与具体业务相关的用户数据配置情况。为了判断AS是否成功执行了业务，可以让S-CSCF在触发时添加一个标签，如果AS成功执行，则在返回的请求消息中继续保存该标签，如果AS没有执行，则在返回的请求消息中删除该标签，S-CSCF据此判定AS是否成功执行了业务，并判定下一个不相容的业务是否可以被触发。
3.3.3 AS返回错误响应情况下的改进
当某个AS返回一个错误响应的时候，S-CSCF会立刻将响应送回主叫方，而不会继续匹配剩下的iFC，后续原本可以执行的AS将由于之前AS的错误而失去了执行机会。然而在许多情况下，S-CSCF可以在前面的AS返回错误响应时，继续触发后续AS。为此，可以在iFC中设置某个选项，以决定在先前AS返回错误响应时是否还要继续触发，若要继续触发，则S-CSCF将根据原始的请求消息对下一条iFC进行匹配。
3.3.4 扩充SPT
目前的SPT定义了5个触发点类型，然而某些业务的触发需要考察终端的能力，例如CSI业务，为了解决这种情况下的问题，扩充了一个新的触发点类型：终端能力。用户在注册过程中将终端能力通知S-CSCF，如果业务需要，S-CSCF可以检查终端能力是否匹配。
3.3.5 携带触发的业务信息
在一般情况下，一个AS中可以部署多个业务。iFC中只标明了应该触发的AS的地址，而没有指出具体业务名称。这样，当请求到达AS的时候，AS并不知道究竟该触发哪一个业务。为此，将iFC中AS地址改为“业务名称@AS”的形式，并将它放置于S-CSCF传给AS消息的Route头域中，AS根据业务名称来触发相应业务。
另外，如果用户订阅了一个AS中的多个业务，并且这些业务的iFC优先级是相邻的，而S-CSCF针对每一个业务分别触发一次，这样消息将在S-CSCF与同一个AS之间来回多次，势必造成不必要的延迟。因此可以考虑将原来各个业务的iFC归并为一条，一次性触发AS将多个业务执行完毕后返回给S-CSCF。为此，需要iFC添加一个项，指示AS中哪些业务应该被一次性执行以及执行顺序。
4、结束语
业务交互问题是影响IMS实际部署和运营的一个重要问题。合理有效地解决业务交互问题，不仅可以快速、经济地提供新业务，还可以减少业务之间的冲突，从正反两方面共同提高用户满意度。但是，由于业务交互问题自身的复杂性，特别是业务冲突问题目前仍然处于研究阶段，离实际应用还有一段距离。目前常采用的冲突检测和解决方法仍然是通过人工方式识别冲突，然后修改业务逻辑或部署方式来解决，而业务协作方面的研究相对更为成熟，所以如何通过SCIM来组合已有业务能力，是目前的研究热点之一。
