3GPP组织对SCIM的功能和控制流程进行了进一步研究，在TR23.810中对ServiceBroker（即SCIM）的功能需求以及部分交互流程的控制方式和改进方式提出了建议。
3.1Service Broker的功能需求
从总体上说，Service Broker提供一个可管理、可控制的手段让多个业务按照用户预想的方式执行。它掌握用户的业务订购情况，明确这些业务该按照何种顺序被触发，并且能够对存在冲突的业务进行协调。
对于Service Broker功能上的需求目前达成共识的主要有以下几点：
●尽可能减小因Service Broker的引入而对IMS核心网造成的影响；
●Service Broker必须采用灵活的架构以便能够应付新业务之间的交互问题；
●支持业务交互，即业务组合以及避免业务冲突；
●Service Broker应能够管理IMS应用与非IMS应用之间的交互；
●支持传统智能网与IMS业务的交互；
●支持不同接入方式的业务之间的交互，如UMTS、WiMAX、WLAN；
●支持SIP与非SIP业务之间交互；
●支持不同业务提供商的业务之间的交互；
●支持由用户配置、控制业务交互的方式。
3.2 ServiceBroker实现方式
TR23.810提出了ServiceBroker的3种实现方式，分别是集中控制、分布式控制、混合式控制（如图1～3所示）。
图1 集中控制
集中控制方式由一个ServiceBroker来协调控制所有业务之间的交互，S-CSCF把ServiceBroker视为AS，通过ISC接口与惟一的ServiceBroker联系，Service Broker与AS之间的接口仍然是ISC接口，这种方式容易实现，但是Service Broker容易成为网络中的瓶颈。
图2 分布式控制
分布式控制方式为每一个AS都配置一个ServiceBroker，S-CSCF把每个ServiceBroker都视作AS，通过ISC接口与其交互。S-CSCF将请求触发给ServiceBroker，AS执行完后，Service Broker可以向S-CSCF发送sFC（subsequent filter criteria）以指示S-CSCF该如何触发接下来的业务，这样Service Broker可以根据冲突关系，动态地将后续业务排除出业务链，这种方式可以解决集中式方式的瓶颈问题，但是实现较为复杂，控制流程也较难设计。
混合式控制结合了上述两种方式，即有的ServiceBroker管理多个AS之间的业务交互，而有的ServiceBroker只和一个AS交互。在这种模式下，ServiceBroker不但要管理由它控制的AS之间的业务交互，还要管理属于不同Service Broker的AS之间的业务交互。图3（a）、（b）是两种可能的实现方式。
图3 混合控制
3.3交互流程改进
影响SCIM实际应用的重要原因之一是SCIM的处理流程并不规范和统一，这不仅使SCIM对于业务交互的处理范围、处理方式都“无章可循”，而且SCIM与网络中其他实体之间也难以互通。TR23.810中对部分实际遇到的交互问题提出了改进意见，这其中一部分改进可以由SCIM来完成，另一部分可以脱离SCIM，直接改进现网中的设备。
3.3.1请求URI被修改的情况
SIP请求中的请求URI实际承担着两种角色：一是代表被服务的对象，被叫侧S-CSCF根据请求URI中所指示的共有用户标识进行iFC触发；二是代表着会话的目的地址，S-CSCF根据请求URI所指示的共有用户标识来进行路由，然而在业务触发阶段，某个AS可能改变了请求消息中的请求URI，结果S-CSCF将消息发往新的目的地，这导致后续本该被触发的AS无法被正常触发。因此，TR23.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.3AS返回错误响应情况下的改进
当某个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可以检查终端能力是否匹配。
