CN101102266B - 基于分组网络的路由方法及系统 - Google Patents

Abstract

本发明实施例公开了一种基于分组网络的路由方法，该方法包括：分组网络中的业务触发点获得判定会话请求是否需要被路由到业务执行点的路由判定信息；业务触发点收到与用户相关的会话请求后，根据该会话请求与用户路由过滤规则匹配的结果和所收到的路由判定信息确定是否将会话请求路由到业务执行点。本发明实施例还基于上述方法公开了一种基于分组网络的路由系统。本发明实施例提供的方法及系统可以减少从业务触发点到业务执行点的路由冗余，减少会话请求中不必要的延时，提高呼叫会话效率。

Description

基于分组网络的路由方法及系统

技术领域

本发明涉及电信领域的路由技术，尤其涉及一种基于分组网络的路由方法及系统。

背景技术

随着分组技术的不断成熟，基于电路交换的传统电信网正在向着基于分组交换的宽带电信网发展，国际电信联盟-电信部分(ITU-T)和欧洲电信标准协会(ETSI)等标准组织都采用IP多媒体子系统(IMS)的网络架构作为下一代网络(NGN)的核心网，并使用会话初始化协议(SIP)作为电信核心网的呼叫控制信令。

IMS是一个基于SIP的体系，为服务的调用提供方法，称为服务提供(Service Provision)。在IMS网络中，通常包括归属用户服务器(HSS)、应用服务器(AS)和服务呼叫会话控制功能(S-CSCF)。AS提供增值多媒体服务，例如呼叫转移、来电显示等，一个AS可以为用户提供一个或多个服务，一个用户也可以拥有多个服务，即可以对应一个或多个AS；S-CSCF提供会话控制服务。IMS服务提供的基本步骤是：运营商或服务提供商定义服务或服务集合；用户订购或修改运营商或服务提供商提供的服务时，以初始过滤规则(iFC)的形式创建用户专有的服务数据；S-CSCF根据iFC将用户发送的与iFC匹配的SIP请求发送给相应的AS。

其中，iFC由0或1个触发点实例和一个AS实例组成，触发点实例用于判断用户发送的SIP请求是否应该发送到iFC中指定的AS。触发点实例包括一个或多个服务点触发器(SPT)，SPT将请求统一资源标识(Request-URI)、SIP方法、SIP消息头、会话情形和会话描述等通过逻辑表达式，例如与、或、非，组合起来。由此可见，iFC就相当于是判决条件，用于指示用户发送的与iFC匹配的SIP请求应该发送到iFC指定的AS中。iFC嵌入到用户配置中，从用户的HSS传送到为用户所分配的S-CSCF。

通常情况下，用户注册时，HSS将用户的iFC传送给为该用户服务的S-CSCF，用户发送的SIP请求或发送到用户的SIP请求到达S-CSCF时，S-CSCF根据iFC将与iFC匹配的SIP请求发送至iFC指定的AS，AS收到SIP请求后，执行相应的业务处理。AS执行业务处理往往是基于业务数据的，在某些情况下，例如没有业务数据时，AS收到SIP请求后，不做任何处理，这样，S-CSCF根据iFC将SIP请求路由到AS，将带来延时，同时也会造成路由冗余。例如，对于无条件前转业务，用户有实施该业务的权限，但是用户如果没有登记需要前转的号码，对于无条件前转业务的AS来说，相当于该用户没有业务数据，对于这样的用户，S-CSCF根据iFC将SIP请求路由到无条件前转的AS时，AS不需要做任何处理，因此，造成了从S-CSCF到AS的路由冗余。

针对上面提到的路由冗余问题，ETSI下属TISPAN第10次会议的意大利电信投稿10TD072中提出一种解决方案：AS通过AS和HSS之间的Sh接口向HSS传送的数据部分中增加动态业务激活信息(DSAI)，一个DSAI数据可以赋值为激活(ACTIVE)或未激活(INACTIVE)，DSAI与iFC绑定，每个DSAI至少绑定一个iFC，每个iFC绑定零个或一个以上的DSAI。这样，HSS向S-CSCF提供的iFC必须遵守的条件是：没有DSAI绑定iFC，或者至少有一个绑定的DSAI赋值为ACTIVE。于是，S-CSCF根据iFC将SIP请求路由到AS时，增加了对DSAI的判断，可以减少路由到AS的请求，从而达到减少路由冗余的目的。

然而，在该投稿给出的方案中没有指出DSAI的来源，更没有指出DSAI如何与iFC绑定；而且iFC是基于用户的，本身与业务没有必然的联系，而DSAI却是一种动态业务激活信息，DSAI具体与用户的哪个iFC绑定在该文中也没有给出具体实现。即使AS向HSS发送DSAI的同时携带用户的公共身份标识和AS信息以实现DSAI与iFC的绑定，但是从3GPP TS 29.228标准规定的用户配置模型中可以得知HSS上的iFC基于用户的私有身份标识，而多个私有身份可能共用同一个公共身份标识，所以为了找到与带有用户公共身份标识和AS信息的DSAI相匹配的iFC，在绑定DSAI和iFC时，必须遍历HSS上的所有iFC，因此，这种绑定效率较低，且较复杂。

此外，上述投稿给出的方案所适用的只是用户数据为永久用户数据的情况，所谓永久用户数据，即该用户数据一旦被设置，那么该用户数据将对所有符合条件的呼叫生效，直至该用户数据被撤销。上述方案并没有考虑用户数据是临时用户数据的情况，所谓临时用户数据，即该用户数据只针对特定呼叫有效，如被临时激活的业务。由于被临时激活的业务通常是针对具体用户的，即该业务并非对所有符合条件的呼叫生效，因此可作为一种临时用户数据。举例说明，对于多个存在业务交互的AS，如AS1与AS2来说，在调用AS1时，需要将调用该AS1的调用消息发送给AS2，使AS2感知，AS2基于AS1被调用后可能出现的变化，再相应地处理业务，该过程为AS1与AS2的业务交互。由于业务交互一般都是在呼叫中完成，属于一种被临时激活的业务，并且，使AS2感知的前提是AS2已经被调用，若AS2没有被调用，那么将调用AS1的消息发往AS2也就是一种冗余路由，因此，上述投稿给出的方案并不能处理该种情况下可能出现的路由冗余。

上述各种现状所存在的一个共同问题是，没有一种好的实现方法可以减少从S-CSCF到AS的路由冗余。

发明内容

有鉴于此，本发明实施例提供一种基于分组网络的路由方法，可以减少分组网络中从业务触发点到业务执行点的路由冗余，具体地，该方法包括：

A、分组网络中的业务触发点获得判定会话请求是否需要被路由到业务执行点的路由判定信息；

B、业务触发点收到与用户相关的会话请求后，根据该会话请求与用户路由过滤规则匹配的结果和所收到的路由判定信息确定是否将会话请求路由到业务执行点。

所述路由判定信息为用户是否为业务执行点所期待；步骤B中所述确定是否将会话请求路由到业务执行点为：判断所述用户是否是业务执行点所期待的用户，如果是，将所述会话请求路由到业务执行点；否则，放弃所述匹配成功后路由至该业务执行点的处理。所述判断用户是否为业务执行点所期待包括：判断用户是否在业务执行点所期待的用户列表中，或者判断用户是否具有业务执行点所期待的标志。

在所述步骤A之前，该方法包括：

业务触发点向业务执行点订阅路由判定信息。

所述路由判定信息为路由过滤规则及其绑定的是否激活的信息；

步骤B中所述确定是否将会话请求路由到业务执行点为：

将与路由过滤规则匹配且该路由过滤规则激活，或者与路由过滤规则匹配且该路由过滤规则没有绑定是否激活信息的会话请求路由到业务执行点。

所述路由判定信息进一步包括：业务执行点所期待的SIP消息内容，该SIP消息内容至少包括下述一种：SIP方法、请求URI、头域或消息体。

步骤A中所述将路由判定信息发送给业务触发点，包括：在SIP消息或Diameter消息中携带路由判定信息发送给业务触发点。

所述步骤A包括：业务执行点将路由判定信息发送给网络数据库，网络数据库将路由判定信息发送给业务触发点。

所述路由判定信息为路由过滤规则及其绑定的是否激活的信息时，所述网络数据库将路由判定信息发送给业务触发点，包括：

网络数据库对路由过滤规则是否激活的信息进行判断，选择没有绑定是否激活信息的路由过滤规则或至少有一个所绑定的信息是激活的路由过滤规则发送给业务触发点。

所述网络数据库为归属用户服务器HSS。

在所述步骤A之前，该方法进一步包括：

业务执行点从网络数据库上获取路由过滤规则，根据用户业务数据的更新情况，将路由过滤规则及其是否激活的信息绑定。

所述分组网络可以为网际协议多媒体子系统IMS网络，所述路由过滤规则可以为用户签约的服务配置(service profile)。

所述业务执行点可以为应用服务器AS，所述业务触发点可以为服务呼叫会话控制功能S-CSCF和/或服务代理Service Broker。

该方法进一步包括：所述路由判定信息改变，业务执行点通知新的路由判定信息给业务触发点；或者将所改变的路由判定信息通知给业务触发点。

所述路由判定信息为是否存在用户对该业务执行点的用户临时数据。

所述分组网络中的业务触发点获得判定会话请求是否需要被路由到业务执行点的路由判定信息具体为：

业务触发点在初次调用业务执行点后，判断是否调用成功，若调用成功，则记录所述临时用户数据，获得所述用户临时数据存在的路由判定信息；

或者，业务触发点根据用户配置的所述用户临时数据，获得所述用户临时数据存在的路由判定信息；

或者，业务触发点根据业务执行点产生的所述临时用户数据，获得所述临时用户数据存在的路由判定信息。

步骤B中所述确定是否将会话请求路由到业务执行点为：

根据所述临时用户数据存在的路由判定信息，确定将会话请求路由到业务执行点。

本发明实施例还提供一种基于分组网络的路由系统，可以减少分组网络中从业务触发点到业务执行点的路由冗余，该系统包括：

网络数据库、业务触发点和业务执行点；其中，

网络数据库，用于存储业务数据，将业务数据信息传送给业务触发点；

业务触发点，用于获取判定与用户相关的会话请求是否需要被路由到业务执行点的路由判定信息，根据所述路由判定信息，以及接收到的所述会话请求和业务数据信息的用户路由过滤规则匹配的结果，确定是否将会话请求路由到业务执行点。

所述业务触发点包括：会话请求接收单元、路由判定信息获取单元和路由确定单元；其中，

会话请求接收单元，用于接收与用户相关的会话请求，将所述会话请求传送给路由确定单元；

路由判定信息获取单元，用于获取判定会话请求是否需要被路由到业务执行点的路由判定信息，将所述路由判定信息传送给路由确定单元；

路由确定单元，用于接收来自路由判定信息获取单元的所述路由判定信息，和来自会话请求接收单元的所述会话请求，和来自网络数据库的业务数据信息，根据所述路由判定信息，所述会话请求和业务数据的用户路由过滤规则匹配的结果，确定是否将会话请求路由到业务执行点。

所述业务触发点进一步包括：会话请求发送单元，用于从路由确定单元获取将会话请求路由到业务执行点的路由确定结果，将会话请求发送给业务执行点。

所述业务执行点包括：

路由判定信息发送单元和会话请求处理单元；其中，

路由判定信息发送单元，用于将所述路由判定信息发送给业务触发点；

会话请求处理单元，用于接收来自业务触发点的会话请求，处理该请求。

所述业务触发点进一步包括：路由判定信息订阅单元，用于向业务执行点订阅所述路由判定信息。

从以上技术方案可以看到，本发明提供的基于分组网络的路由方法及系统具有以下有益效果：

1、本发明中，业务执行点将路由判定信息预先发送给业务触发点，业务触发点除了需要根据路由过滤规则判断与用户相关的会话请求是否匹配路由过滤规则以外，还根据所获得的路由判定信息增加对与用户相关的会话请求进行判断，由于增加了路由判定信息的机制，因此减少了从业务触发点到业务执行点的路由冗余；

2、由于可以减少从业务触发点到业务执行点的路由冗余，所以可以进一步减少会话请求不必要的时延，提高呼叫会话效率。

附图说明

图1是根据本发明的网络逻辑结构图；

图2是根据本发明实施例一的路由方法流程图；

图3是根据本发明实施例一的无条件呼叫前转业务的路由方法流程图；

图4是根据本发明实施例二的无条件呼叫前转业务的路由方法流程图；

图5是根据本发明实施例三的路由方法流程图。

具体实施方式

为了使本发明的特征和优点更加清楚明白，下面参照附图结合具体实施例对本发明作进一步的描述。

从背景技术的描述可知，为用户服务的S-CSCF根据iFC将与用户相关的SIP请求，包括用户发送的SIP请求或者发送到用户的SIP请求，路由到AS时，如果AS不执行任何业务处理，仅仅是转发该消息，那么将造成路由冗余。针对这种情况，本发明提出一种解决方案，该方案的主要思想是：业务执行点预先发送路由判定信息，业务触发点在收到与用户相关的会话请求时，根据与用户路由过滤规则匹配的结果和路由判定信息判断该用户的请求是否需要被路由到业务执行点，由于在原有与用户路由过滤规则匹配基础上增加了路由判定信息的判断机制，有效地减少了不必要的会话请求被路由到业务执行点的问题，从而达到了减少路由冗余的目的。

这里，路由判定信息用于判定与用户相关的会话请求是否需要被路由到业务执行点，可以是：业务执行点所期待请求的用户列表、用户是否具有业务执行点所期待的标志或路由过滤规则及其绑定的是否激活的信息。业务执行点预先发送路由判定信息，可以是直接发送给业务触发点，也可以是发送给网络数据库，由网络数据库转发给业务触发点，或者业务触发点从网络数据库上获得该路由判定信息。

下面以基于分组网络的路由方法为例，描述本发明的具体实现，由于IMS网络是基于分组网络的一种典型系统，为描述的方便，本发明中以IMS网络为例，但不意味着本发明的方法仅能用于IMS网络。在以下实施例中，路由过滤规则为用户签约的服务配置(service profile)中的iFC，网络数据库为HSS。

首先参见图1，描述根据本发明实施例的基于分组网络基于IMS网络的路由系统。图1所示的系统包括：网络数据库，这里是HSS、业务执行点和业务触发点。

网络数据库用于存储所有与用户和服务相关的业务数据，将将业务数据信息传送给业务触发点。当网络数据库为HSS并且网络中存在多个可以独立寻址的HSS时，业务执行点和业务触发点能够利用一种地址解析机制找到拥有给定用户身份的订购关系数据的归属用户服务器地址。

业务触发点，用于获取判定与用户相关的会话请求是否需要被路由到业务执行点的路由判定信息，根据所述路由判定信息，以及接收到的所述会话请求和业务触发数据的用户路由过滤规则匹配的结果，确定是否将会话请求路由到业务执行点。

业务触发点与业务执行点通过E3接口进行交互，提供会话控制服务，E3接口的协议可以是SIP协议。业务触发点通过E2接口从HSS获得用户配置数据，E2接口的协议可以是Diameter协议，这里的用户配置数据包括iFC，业务触发点可以根据iFC将与用户相关的请求路由到iFC所指定的业务执行点。业务触发点可以是IMS网络中的S-CSCF和/或服务代理ServiceBroker等。本发明的业务执行点预先发送路由判定信息，业务触发点根据与用户相关的会话请求与iFC匹配的结果和路由判定信息判断是否需要将会话请求路由到业务执行点。

业务执行点是提供服务的功能实体，一个业务执行点可以提供一个服务，也可以提供多个服务。业务执行点通过E1接口从HSS获得用户数据，E1接口的协议可以是Diameter协议，业务执行点可以是IMS网络中的AS。

上述业务触发点可包括：会话请求接收单元、路由判定信息获取单元和路由确定单元；其中，

会话请求接收单元，用于接收与用户相关的会话请求，将所述会话请求信息传送给路由确定单元；

路由判定信息获取单元，用于获取判定会话请求是否需要被路由到业务执行点的路由判定信息，将所述路由判定信息传送给路由确定单元；

路由确定单元，用于接收来自路由判定信息获取单元的所述路由判定信息，和来自会话请求接收单元的所述会话请求信息，和来自网络数据库的业务数据信息，根据所述路由判定信息，所述会话请求和业务数据的用户路由过滤规则匹配的结果，确定是否将会话请求路由到业务执行点。

业务触发点进一步包括：会话请求发送单元，用于从路由确定单元获取将会话请求路由到业务执行点的路由确定结果，将会话请求发送给业务执行点。

业务执行点包括：路由判定信息发送单元和会话请求处理单元；其中，

路由判定信息发送单元，用于将所述路由判定信息发送给业务触发点；

会话请求处理单元，用于接收来自业务触发点的会话请求，处理该请求。

业务触发点进一步包括：路由判定信息订阅单元，用于向业务执行点订阅所述路有判定信息。

下面参照附图通过三个实施例描述基于图1所示系统的路由方法。

实施例一

本实施例中业务执行点预先发送的路由判定信息是用户是否在业务执行点所期待请求的用户列表，该路由判定信息直接发送给了业务触发点。该用户列表反映业务执行点需要对哪些用户的请求做业务处理。

具体地，参见图2，本实施例的过程为：

步骤201-202、业务触发点向业务执行点订阅业务执行点所期待请求的用户列表；业务执行点将所期待请求的用户列表发送给业务触发点；

用户在网络中注册时，HSS就将所创建的该用户的iFC发送给业务触发点，所以业务触发点可以获取到iFC中指定的AS，这里就是业务执行点，从而维护该业务执行点的用户列表，当存在多个业务执行点时，业务触发点需要维护每个业务执行点的用户列表，业务触发点可以用SIP协议中的Subscribe消息向每个业务执行点订阅业务执行点所期待请求的用户列表，然后业务执行点在Notify消息中将期待请求的用户列表发送给业务触发点。

当业务执行点所期待请求的用户列表改变时，业务执行点可以在Notify消息中携带新的所期待请求的用户列表或者期待的用户列表发生改变的内容发送给业务触发点。

在SIP消息中扩展表示期待请求的用户列表的订阅请求的事件包如：事件(Event)：expectant-uri-list。如果订阅被接受，业务执行点生成Notify消息来携带期待请求的用户列表信息，该信息包括一个含有类型名称、子类型名称、所需参数和解码类型信息的MIME类型字段，具体信息如下：

Media type name:application；

Media subtype name:expectant-uri-list+xml；

Required parameters:none；

Encoding scheme:xml。

例如：在Notify请求中携带如下xml信息：

<？xml version＝″1.0″encoding＝″UTF-8″？>

<url-list xmlns:xsi＝″http://www.w3.org/2001/XMLSchema-instance″

xsi:noNamespaceSchemaLocation＝″C:\UserProfile\expectant_uri_list.xsd″>

  <uri-desc change-description＝″add″>

     <uti>tobias@home.com</uri>

  </uri-desc>

  <uri-desc change-description＝″add″>

        <uri>mary@home.com</uri>

  </uri-desc>

  <uri-desc change-description＝″delete″>

     <uri>tom@home.com</uri>

  </uri-desc>

</uri-list>

上述xml描述给出的信息是：当前业务执行点希望在原有期待的用户列表中新增(add)用户tobias@home.com和mary@home.com，删除(delete)用户tom@home.com。

业务触发点除了采用SIP协议的Subscribe消息向业务执行点订阅其所期待请求的用户列表以外，还可以在其它消息中采用Subscription头域的方式订阅所期待请求的用户列表，关于Subscription头域的方式在IETF标准组织的一篇草案(draft-rosenberg-sipping-reg-sub-00.txt)中有详细说明，这里不再赘述。

以上所述是业务触发点发送订阅消息订阅业务执行点所期待请求的用户列表，进一步地，业务执行点也可以主动发送自己所期待请求的用户列表，例如：业务执行点采用在SIP协议的Info、Publish等消息中携带所期待请求的用户列表发送给业务触发点。

此外，业务执行点除了可以采用与用户会话处理无关的Info、Publish等消息主动发送自己所期待请求的用户列表外，还可利用用户的会话处理消息，例如Invite、Message等会话请求消息的响应消息，比如，业务触发点向业务执行点发送Invite消息，业务执行点在返回的响应消息中携带所期待请求的用户列表。

步骤203-205、业务触发点收到用户发送的请求，并且该请求与iFC匹配，业务触发点根据匹配得到的业务执行点所期待请求的用户列表，判断发送请求的用户是否在该所期待请求的用户列表中，如果是，则将该请求路由到iFC指定的业务执行点；否则，放弃将该请求路由到iFC指定的业务执行点。

实际应用中，用户可能拥有多个iFC，每个iFC在S-CSCF上都有不同的优先级，S-CSCF会根据iFC的优先级依次与用户的请求相匹配，进而进行判断确定是否路由到iFC指定的业务执行点。因此，在步骤205中放弃将该请求路由到iFC指定的业务执行点后，业务触发点还会根据该用户其它iFC在业务触发点上的优先级，继续判断用户发送的请求是否与下一优先级的iFC相匹配，并判断用户是否在下一优先级的iFC指定的业务执行点所期待请求的用户列表中。

以上描述的是业务触发点处理的会话请求都是用户主动发送的请求，即处理的是主叫用户，事实上发送给用户的请求到达为用户服务的业务触发点后，业务触发点同样可以利用本发明中的路由方法，即可以处理被叫用户，这同样适用于本发明中的其它实施例。进一步，在业务执行点发送的所期待请求的用户列表中，还可以给出所期待请求的SIP消息内容，即用户列表中除了给出用户标识以外，还针对每个用户给出期待请求的SIP消息内容，SIP消息内容可以是SIP消息中的任意内容，包括SIP方法、请求URI、头域和消息体。这样，业务触发点在将用户发送的请求路由到业务执行点时，除了需要匹配iFC，并且发送请求的用户处于所期待请求的用户列表中之外，还需要匹配iFC成功的SIP消息内容与所期待请求的用户列表中的SIP消息内容相匹配，只有都匹配成功的请求才被路由到业务执行点。此方法同样适用于本发明中的其它实施例。

例如，业务执行点如果是处理无条件前转业务的业务执行点，那么它所期待请求的SIP消息是SIP Invite消息，如果该业务执行点同时还可以处理即时消息黑白名单业务，那么它所期待请求的SIP消息是SIP Message消息，这样，当用户订购了无条件前转业务而没有订购即时消息黑白名单业务时，该业务执行点向业务触发点发送的所期待请求的用户列表中，除了给出所期待请求的用户标识以外，还可以给出针对该用户期待的SIP消息内容，即Invite消息，这样，当用户发送Invite消息至业务触发点时，匹配iFC成功，业务触发点再判断该用户是否在业务执行点期待请求的用户列表中，该用户在期待请求的列表中并且发送的SIP消息也匹配用户列表中给出的SIP消息内容，于是业务触发点将Invite消息路由到对应的业务执行点；如果用户发送Message消息至业务触发点时，匹配iFC成功，然而虽然该用户的标识在所期待请求的用户列表中，但是业务执行点所期待请求的SIP消息是Invite而不是Message，所以业务触发点不会将该Message消息路由到业务执行点。

另外，因为业务执行点上归属服务的用户可以分布在一个以上的业务触发点上，所以业务执行点在向业务触发点发送自身所期待的用户列表之前，必须要先获知哪些用户归属于哪个业务触发点上，对此，一般可以有如下三种解决方法：

用户在注册到业务触发点后，向业务执行点发起第三方注册，业务执行点记录下业务触发点和其归属的用户；

HSS上保存的用户签约数据包括用户所归属的业务触发点，业务执行点可以从HSS上获取用户所归属的业务触发点，业务执行点记录下业务触发点和其归属的用户；

业务触发点向业务执行点订阅用户是否为业务执行点所期待，业务执行点记录下业务触发点和其归属的用户。

下面参见图3，以IMS网络中用户tom@home.com的无条件前转业务为例，给出以上所描述方法的具体实现。

步骤301-304、业务触发点通过Subscribe消息向无条件前转业务执行点订阅当前期待请求的用户列表，无条件前转业务执行点当前期待请求的用户列表为tom@home.com，在Notify消息中发送给业务触发点；

步骤305-308、用户tom@home.com发起会话请求，Invite消息发送至业务触发点，业务触发点将当前会话请求Invite消息匹配iFC，得到无条件前转业务执行点，并进一步判断用户tom@home.com在无条件前转业务执行点期待请求的用户列表中，于是，将该会话请求路由到无条件前转业务执行点；

步骤309-310、无条件前转业务执行点上用户tom@home.com的标识被删除，这里，可以是无条件前转业务执行点主动删除，也可以是用户向无条件前转业务执行点发送删除命令来删除；无条件前转业务执行点进一步在Notify消息中通知业务触发点删除用户tom@home.com。

步骤311-314、用户tom@home.com再次发起会话请求时，Invite消息发送至业务触发点，业务触发点将当前会话请求匹配iFC，得到对应的无条件前转业务执行点，并进一步判断用户tom不在无条件前转业务执行点期待请求的用户列表中，于是，将该会话请求路由到其它期待请求该用户的业务执行点或者直接路由到被叫方。

从实施例一的描述可以看到，由于业务执行点预先将所期待请求的用户列表发送给业务触发点，这样业务触发点在路由用户请求到业务执行点时根据期待请求的用户列表增加对该用户的判断，使业务执行点期待的请求才发送到业务执行点，从而减少路由冗余。

实施例二

本实施例中业务执行点预先发送的路由判定信息是用户是否具有业务执行点所期待的标志，也即业务执行点是否期待该用户的请求，具体实现时采用是否期待的标志即true和false来指示。在实施例中该路由判定信息直接发送给了业务触发点。

本实施例与实施例一类似，具体过程如下：业务触发点在获得用户的iFC后，向iFC中指定的业务执行点订阅业务执行点是否期待创建该用户的请求，业务执行点将是否期待该用户的请求发送给业务触发点；当该用户发送请求至业务触发点，并且业务触发点判断用户的请求匹配iFC后，业务触发点进一步根据业务执行点发送的是否期待该用户的请求来判断业务执行点是否期待该用户请求的到来，如果该用户为业务执行点所期待，将请求路由到该业务执行点，反之，放弃路由到该业务执行点。

与实施例一类似，当业务执行点对该用户到来的请求的期待发生改变时，业务执行点会将该改变通知给业务触发点；业务执行点也可以主动将是否期待用户的请求发送给业务触发点；业务触发点可以用SIP协议中的Subscribe消息向业务执行点订阅是否期待该用户的请求；业务触发点采用什么样的消息订阅以及业务执行点在什么样的消息中将结果返回给业务触发点都与实施例一相同，这里不再赘述。不同的是，实施例一中订阅的是业务执行点期待的用户列表，实施例二中订阅的是某个具体用户是否为业务执行点所期待，具体地，本实施例中业务触发点在SIP消息中扩展表示是否期待该用户的请求的订阅请求的事件包如：Event：expectant-request，并通过参数指明该用户标识。如果订阅被接受，业务执行点生成Notify请求来携带期待该用户到来的请求信息，该信息包含一个application/expectant-request的MIME类型字段，具体如下：

Media type name:application；

Media subtype name:expectant-request；

Required parameters:none；

Encoding scheme:xml。

例如：在Notify请求中携带如下xml信息：

<？xml version＝″1.0″encoding＝″UTF-8″？>

   <expectant-requestxmlns:xsi＝http://www.w3.org/2001/XMLSchema-instance

   xsi:noNamespaceSchemaLocation＝″C:\UserProfile\expectant_request.xsd″>

   <result uri＝″tom@home.com″>true</result>

</expectant-request>

上述xml描述给出的信息是：当前业务执行点期待用户tom@home.com请求的到来。

下面参见图4，以IMS网络中用户tom@home.com的无条件前转业务为例，给出以上所描述方法的具体实现。

步骤401-404、用户在网络中注册时，HSS就将用户的iFC发送给业务触发点，业务触发点可以获得iFC中指定的业务执行点。业务触发点通过Subscribe消息向iFC中指定的无条件前转业务执行点订阅是否期待用户tom@home.com的请求，无条件前转业务执行点期待用户tom@home.com，在Notify消息中携带true发送给业务触发点；

步骤405-408、用户tom@home.com发起会话请求，Invite消息发送至业务触发点，业务触发点将当前会话请求匹配iFC，得到对应的无条件前转业务执行点，并进一步判断无条件前转业务执行点期待用户tom@home.com的请求，于是，将该会话请求路由到无条件前转业务执行点；

步骤409-410、无条件前转业务执行点上用户tom@home.com的业务数据被删除，这里，可以是无条件前转业务执行点主动删除，也可以是用户向无条件前转业务执行点发送删除命令来删除；无条件前转业务执行点进一步在Notify消息中携带“false”通知业务触发点不期待用户tom@home.com。

步骤411-414、用户tom@home.com再次发起会话请求时，Invite消息发送至业务触发点，业务触发点将当前会话请求匹配iFC，得到对应的无条件前转业务执行点，并进一步判断无条件前转业务执行点不期待用户tom@home.com的请求，于是，将该会话请求路由到其它期待该用户的业务执行点或者直接路由到被叫方。

在以上两个实施例中，业务执行点预先将路由判定信息直接通知给业务触发点，例如采用SIP Notify消息通知给业务触发点等。事实上，业务执行点预先通知的路由判定信息也可以不直接通知给业务触发点，例如业务执行点通过E1接口的Diameter消息预先将路由判定信息主动发送给HSS，由业务触发点在需要的时候从HSS上获取该路由判定信息或者由HSS主动发送给业务触发点。

可以看到，实施例一和实施例二相同之处在于：业务触发点处理用户会话请求，在获得业务执行点的地址后，根据业务执行点预先发送的路由判定信息，判断该用户是否是该业务执行点所期待的用户，以决定是否将该会话请求路由至该业务执行点；不同之处在于两个实施例的路由判定信息的表现方式的不同。

实施例三

本实施例中业务执行点预先发送给业务触发点的路由判定信息是用户的iFC和该iFC是否激活的指示。

从背景技术的描述可知，意大利电信投稿10TD072中提出的解决方案仅说明AS将DSAI通知给HSS，而没有给出DSAI与用户的哪个iFC绑定，并且即使AS在将DSAI发送给HSS的同时，携带用户的公共身份标识和AS信息，但是仍然是一种效率低、复杂度高的绑定。事实上，如果AS能将DSAI和对应的iFC同时发送给HSS，那么将可以解决DSAI和iFC的绑定问题，本实施例正是基于这种思想。

参见图5，描述本实施例的具体实现过程，该过程包括：

步骤501-502、业务执行点从HSS上获取用户的iFC，用户的业务数据更新后，业务执行点将触发到该业务执行点的iFC和该iFC是否激活的信息绑定，并发送给业务触发点；

用户的业务数据更新可以包括订购服务、修改服务和取消服务等，例如用户从没有登记无条件前转号码到登记无条件前转号码，用户的业务数据从无到有，则iFC是否激活指示设置为“激活”，例如用户登记了无条件前转号码，有了业务数据；用户的业务数据从有到无，则iFC是否激活指示设置为“未激活”，例如用户删除了无条件前转号码，取消了该订购业务。

这里，业务执行点将iFC及其是否激活的信息直接发送给了业务触发点，业务触发点根据iFC和绑定的iFC是否激活的信息判定是否将请求路由到业务执行点。在具体实现中，业务执行点还可以将iFC及其是否激活的信息发送给HSS，此时，HSS根据业务执行点发送的iFC及其是否激活的信息进一步判断，将满足没有激活指示绑定或者至少有一个绑定的激活指示赋值为“激活”的iFC发送给业务触发点；将所绑定的激活指示赋值为“未激活”的iFC不发送给业务触发点。

进一步，与实施例一和实施例二类似，业务执行点还可以根据自身所处理的业务对应的SIP消息内容确定是否需要将绑定iFC的激活指示设置为“激活”，例如，一个业务执行点既处理无条件呼叫前转业务又处理即时消息前转业务，在用户设置了无条件呼叫前转业务而未设置即时消息前转业务时，该业务执行点期待的SIP消息内容是SIP Invite消息，将Invite消息与从HSS获取的iFC匹配，如果匹配，则将绑定该iFC的激活指示设置为“激活”；否则，设置为“未激活”。例如，将Invite消息与SIP消息内容为Message的iFC匹配，则匹配不成功，应将该iFC的激活指示设置为“未激活”。

步骤503-505、业务触发点收到用户发送的请求，并且该请求与iFC匹配，业务触发点判断iFC是否激活，如果是，则将该请求路由到iFC指定的业务执行点；否则，放弃将该请求路由到iFC指定的业务执行点。

在以上所述的三个实施例中，业务触发点对于与用户相关的会话请求所进行的判断都是首先将会话请求与iFC相匹配，然后再根据路由判定信息确定是否将请求路由到业务执行点；然而，在实际应用中，业务触发点也可以首先根据路由判定信息判断与用户相关的会话请求是否需要被路由到业务执行点，然后再匹配iFC。

实施例四

本实施例中，路由判定信息可以是：是否存在用户对业务执行点的临时用户数据。业务触发点若要确定是否调用业务执行点，则需要判断该业务执行点是否已经被临时调用，即需要判断用户对该业务执行点的临时用户数据是否存在。业务触发点确定是否调用业务执行点的过程如下：

首先，业务触发点在初始调用该业务执行点后，判断是否调用成功，若调用成功，则记录用户对该业务执行点的临时调用成功，即记录下用户对该业务执行点的临时用户数据存在，这样，业务触发点就可获得临时用户数据存在的路由判定信息；

上述业务触发点判断是否调用成功的做法可以是：通过该业务执行点被初始调用后是否有响应返回以及返回的响应内容，判断该业务执行点是否被成功调用，如该业务执行点被初始调用后没有响应、或返回失败响应码、或返回携带有业务调用失败指示的消息等，则表示该业务执行点调用失败，如该业务执行点返回一个SIP初始请求消息、或返回成功响应码、或返回携带有业务调用成功指示的消息等，则表示该业务执行点调用成功。

业务触发点启动上述记录下用户对该业务执行点的临时用户数据的依据可以是：自动记录，或，根据该业务执行点被初始调用的如iFC的过滤规则的配置指示执行记录，或，根据该业务执行点被初始调用后返回的消息携带的指示执行记录。举例说明，如业务触发点执行一个iFC，获得该iFC指示的业务执行点并进行调用，之后，依据该过滤规则中的相关配置指示，启动业务执行点是否调用成功并在调用成功后记录临时用户数据的处理；再如，业务触发点调用业务执行点后，根据该业务执行点返回消息中携带的相关指示，启动业务执行点是否调用成功并在调用成功后记录临时用户数据的处理。

之后，当业务触发点再次调用该业务执行点时，根据是否存在用户对该业务执行点的临时用户数据，判断该业务执行点是否已经被调用，若已经被调用，则再次调用该业务执行点，否则不调用该业务执行点。

业务触发点启动上述判断业务执行点是否已经被调用以判决是否可被再次调用的依据可以是：相关如iFC的过滤规则的配置指示业务执行点被再次调用的条件。如，业务触发点执行一个iFC，获得该iFC指示的业务执行点，且该过滤规则中的相关配置指示该业务执行点只有在已经被调用的前提下才可再次被调用，则业务触发点判断该业务执行点是否已经被调用，即判断是否已经存在用户对该业务执行点的临时用户数据，若是，则再次调用该业务执行点。

至此，业务触发点确定是否调用业务执行点过程告一段落。

下面对本实施例四作进一步说明。

本实施例中，设用户签约了两个AS，分别是iFC1指示的AS1和iFC2指示的AS2，且该两个AS之间存在业务交互关系。为了处理该业务交互，本实施例通过增加一个iFC3，用以指示对其中一个AS的再次调用，需要基于该AS已被调用的临时用户数据来执行该再次调用。处理AS1与AS2业务交互的流程说明如下：

首先，用户发起一个呼叫，发送SIP INVITE1消息，业务触发点收到该INVITE1消息，依据iFC1调用AS1，即向AS1发送调用消息INVITE1消息；在AS1向业务触发点返回INVITE1消息后，业务触发点记录下用户对AS1调用成功的临时用户数据；

此后，业务触发点收到一个以该用户为被叫的呼入来电，即接收到SIPINVITE2消息；业务触发点执行iFC2以调用AS2，即向AS2发送INVITE2调用消息；业务触发点执行iFC3，根据iFC3中配置的“依据用户对AS1的临时用户数据调用”指示，判断该用户是否已经存在对AS1的临时用户数据。由上述业务触发点记录下用户对AS1调用成功的临时用户数据可知，AS1已被调用，则业务触发点再根据iFC3指示的AS1的地址，再次调用AS1，向AS1发送调用消息INVITE2消息。AS1收到该消息后，即可处理业务交互。

在本实施例中，业务触发点直接生成了业务执行点调用的临时用户数据，此外类似的，该临时用户数据还可以由被调用的业务执行点产生，再通知业务触发点，或通过HSS通知业务触发点，这样，业务触发点就可获得临时用户数据存在的路由判定信息。业务触发点执行其他iFC获得该业务执行点时，据此判断是否调用该业务执行点。

或者，临时用户数据还可以是由用户配置到业务执行点，业务执行点将该配置通知HSS。HSS接收到业务执行点的通知后，从业务执行点下载该临时用户数据，并发送给业务触发点，这样，业务触发点就可获得临时用户数据存在的路由判定信息。当业务触发点成功接收到该临时用户数据后，业务执行点向用户返回临时用户数据设置成功的信息给用户。至此，业务触发点即可根据该临时用户数据调用该业务执行点。

此外，在上述的实施方式中，以IMS标准定义的iFC作为实施例加以说明，业务触发点将会话请求和对应iFC匹配以得到业务执行点的路由地址，由此可见，iFC表示的是一种路由过滤规则，因此本发明不仅适用于iFC作为路由过滤规则的情况，也适用于任何形式的路由过滤规则，比如当业务触发点是Service Broker时，对应的路由过滤规则也被称为业务能力交互管理器(SCIM，Service Capability Interaction Manager)过滤规则，事实上，SCIM过滤规则是用户签约的一种订购关系(subscription)，即service profile。

上述实施方式中，以IMS网络作为实施例加以说明，给出了在IMS网络中一种通过传递路由判定信息实现减少不必要路由冗余的方法。IMS网络是以SIP协议为核心网呼叫控制信令的分组网络，在其它的分组网络中，同样可以应用本发明提供的方法通过业务执行点传递路由判定信息减少不必要路由冗余。

此外，上述的实施方式中，业务执行点通过SIP消息、Diameter消息来发送路由判定信息，实际上还可以通过任何合适的分组协议来传送，比如HTTP协议等。

以上参照附图结合具体实施例对本发明进行了详细描述，从以上描述可以看到，本发明的业务执行点通过预先发送路由判定信息，使得业务触发点在路由用户请求至业务执行点之前，根据路由判定信息判定用户的请求是否需要被路由到业务执行点，减少不必要路由到业务执行点的用户请求被路由到业务执行点的问题，从而减少路由冗余，降低延时，提高会话呼叫效率。

以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims (23)

1.一种基于分组网络的路由方法，其特征在于，该方法包括：

A、分组网络中的业务触发点获得判定会话请求是否需要被路由到业务执行点的路由判定信息；

B、业务触发点收到与用户相关的会话请求后，根据该会话请求与用户路由过滤规则匹配的结果和所收到的路由判定信息确定是否将会话请求路由到业务执行点。

2.根据权利要求1所述的方法，其特征在于，步骤A包括：

A1、业务执行点发送判定会话请求是否需要被路由到业务执行点的路由判定信息给业务触发点，由业务触发点接收所述路由判定信息。

3.根据权利要求2所述的方法，其特征在于，所述路由判定信息为用户是否为业务执行点所期待；

步骤B中所述确定是否将会话请求路由到业务执行点为：

判断所述用户是否是业务执行点所期待的用户，如果是，将所述会话请求路由到业务执行点；否则，放弃所述匹配成功后路由至该业务执行点的处理。

4.根据权利要求3所述的方法，其特征在于，所述判断用户是否为业务执行点所期待包括：

判断用户是否在业务执行点所期待的用户列表中，或者判断用户是否具有业务执行点所期待的标志。

5.根据权利要求3或4所述的方法，其特征在于，在所述步骤A1之前，该方法包括：

业务触发点向业务执行点订阅所述路由判定信息。

6.根据权利要求2所述的方法，其特征在于，所述路由判定信息为路由过滤规则及其绑定的是否激活的信息；

步骤B中所述确定是否将会话请求路由到业务执行点为：

将与路由过滤规则匹配且该路由过滤规则激活，或者与路由过滤规则匹配且该路由过滤规则没有绑定是否激活信息的会话请求路由到业务执行点。

7.根据权利要求6所述的方法，其特征在于，在所述步骤A1之前，该方法进一步包括：

业务执行点从网络数据库上获取路由过滤规则，根据用户业务数据的更新情况，将路由过滤规则及其是否激活的信息绑定。

8.根据权利要求3、4或6所述的方法，其特征在于，所述路由判定信息进一步包括：

业务执行点所期待的会话初始化协议SIP消息内容，该SIP消息内容至少包括下述一种：SIP方法、请求统一资源标识URI、头域或消息体。

9.根据权利要求2所述的方法，其特征在于，步骤A1中所述将路由判定信息发送给业务触发点，包括：

在SIP消息或Diameter消息中携带路由判定信息发送给业务触发点。

10.根据权利要求2所述的方法，其特征在于，所述步骤A1进一步包括：

业务执行点将路由判定信息发送给网络数据库，网络数据库将路由判定信息发送给业务触发点。

11.根据权利要求9所述的方法，其特征在于，所述路由判定信息为路由过滤规则及其绑定的是否激活的信息时，所述网络数据库将路由判定信息发送给业务触发点，包括：

网络数据库对路由过滤规则是否激活的信息进行判断，选择没有绑定是否激活信息的路由过滤规则或至少有一个所绑定的信息是激活的路由过滤规则发送给业务触发点。

12.根据权利要求9或10所述的方法，其特征在于，所述网络数据库为归属用户服务器HSS。

13.根据权利要求2所述的方法，其特征在于，该方法进一步包括：

所述路由判定信息改变，业务执行点通知新的路由判定信息给业务触发点；或者将所改变的路由判定信息通知给业务触发点。

14.根据权利要求1所述的方法，其特征在于，所述分组网络为网际协议多媒体子系统IMS网络，所述路由过滤规则为用户签约的服务配置serviceprofile。

15.根据权利要求1所述的方法，其特征在于，所述业务执行点为应用服务器AS，所述业务触发点为服务呼叫会话控制功能S-CSCF和/或服务代理Service Broker。

16.根据权利要求1所述的方法，其特征在于，所述路由判定信息为是否存在用户对该业务执行点的临时用户数据。

17.根据权利要求16所述的方法，其特征在于，步骤A：

业务触发点在初次调用业务执行点后，判断是否调用成功，若调用成功，则记录所述临时用户数据，获得所述临时用户数据存在的路由判定信息；

或者，业务触发点根据用户配置的所述临时用户数据，获得所述临时用户数据存在的路由判定信息；

或者，业务触发点根据业务执行点产生的所述临时用户数据，获得所述临时用户数据存在的路由判定信息。

18.根据权利要求17所述的方法，其特征在于，步骤B中所述确定是否将会话请求路由到业务执行点为：

根据所述临时用户数据存在的路由判定信息，确定将会话请求路由到业务执行点。

19.一种基于分组网络的路由系统，其特征在于，包括：网络数据库、业务触发点和业务执行点；其中，

网络数据库，用于存储业务数据，将业务数据信息传送给业务触发点；

业务触发点，用于获取判定与用户相关的会话请求是否需要被路由到业务执行点的路由判定信息，根据所述路由判定信息，以及接收到的所述会话请求和业务数据信息的用户路由过滤规则匹配的结果，确定是否将会话请求路由到业务执行点。

20.根据权利要求19所述的系统，其特征在于，所述业务触发点包括：会话请求接收单元、路由判定信息获取单元和路由确定单元；其中，

会话请求接收单元，用于接收与用户相关的会话请求，将所述会话请求传送给路由确定单元；

路由判定信息获取单元，用于获取判定会话请求是否需要被路由到业务执行点的路由判定信息，将所述路由判定信息传送给路由确定单元；

路由确定单元，用于接收来自路由判定信息获取单元的所述路由判定信息，和来自会话请求接收单元的所述会话请求，和来自网络数据库的业务数据信息，根据所述路由判定信息，所述会话请求和业务数据的用户路由过滤规则匹配的结果，确定是否将会话请求路由到业务执行点。

21.根据权利要求19或20所述的系统，其特征在于，所述业务触发点进一步包括：会话请求发送单元，用于从路由确定单元获取将会话请求路由到业务执行点的路由确定结果，将会话请求发送给业务执行点。

22.根据权利要求21所述的系统，其特征在于，所述业务执行点包括：

路由判定信息发送单元和会话请求处理单元；其中，

路由判定信息发送单元，用于将所述路由判定信息发送给业务触发点；

会话请求处理单元，用于接收来自业务触发点的会话请求，处理该请求。

23.根据权利要求19所述的系统，其特征在于，所述业务触发点进一步包括：路由判定信息订阅单元，用于向业务执行点订阅所述路由判定信息。

Images