WO2008006313A1

WO2008006313A1 - Procédé et système de routage fondés sur un réseau à commutation par paquets

Info

Publication number: WO2008006313A1
Application number: PCT/CN2007/070221
Authority: WO
Inventors: Bo Zheng; Youzhu Shi
Original assignee: Huawei Technologies Co., Ltd.
Priority date: 2006-07-03
Filing date: 2007-07-03
Publication date: 2008-01-17
Also published as: CN101102266A; CN101102266B

Description

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

技术领域

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

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

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

其中， iFC由 0或 1个触发点实例和一个 AS实例组成，触发点实例用于判断用户发送的 SIP请求是否应该发送到 iFC中指定的 AS。触发点实例包括一个或多个月良务点触发器（SPT, Service point trigger ), 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的路由冗余。

针对上面提到的路由冗余问题，现有的一种解决方案是： AS 通过 AS和 HSS之间的 Sh接口向 HSS传送的数据部分中增加动态业务激活信息 ( DSAI, Dynamic Service Activation Information ), 一个 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, 因此，这种 DSAI 和 iFC绑定的方案效率较低，且实现较复杂。

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

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

本发明实施例提供一种基于分组网络的路由方法，可以减少分组网络中从业务触发点到业务执行点的路由冗余。

一种基于分组网络的路由方法，该方法包括：

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

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

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

网络数据库，用于存储用户路由过滤规则，并将用户路由过滤规则传送给业务触发点；

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

从以上技术方案可以看到，本发明实施例提供的基于分组网络的路由方法及系统具有以下有益效果： 1、本发明实施例中，业务执行点将路由判定信息预先发送给业务触发点，业务触发点除了需要根据路由过滤规则判断与用户相关的会话请求是否匹配路由过滤规则以外，还根据所获得的路由判定信息增加对与用户相关的会话请求进行判断，由于增加了路由判定信息的机制，因此，只将需要被路由的会话路由至对应的业务执行点，从而有效减少了从业务触发点到业务执行点的路由冗余；

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

图 1是本发明实施例中的网络逻辑结构图；

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

图 3是本发明实施例一的无条件呼叫前转业务的路由方法流程图；图 4是本发明实施例二的无条件呼叫前转业务的路由方法流程图；图 5是本发明实施例三的路由方法流程图。实施本发明的方式

下面结合附图及实施例对本发明实施例的技术方案作详细描述。对于分组网络中从业务触发点到业务执行点之间可能存在的路由冗余，如为用户服务的 S-CSCF根据 iFC将与用户相关的 SIP请求，包括用户发送的 SIP请求或者发送到用户的 SIP请求，路由到 AS时，如果 AS 不执行任何业务处理，仅仅是转发该消息，那么将造成路由冗余，本发明实施例给出了可有效解决业务触发点与业务执行点间路由冗余的技术方案。本发明实施例中，业务执行点预先发送路由判定信息，业务触发点在收到与用户相关的会话请求时，根据与用户路由过滤规则匹配的结果和路由判定信息判断该用户的会话请求是否需要被路由到业务执行点，且将需要被路由的会话路由至对应的业务执行点。由于在原有与用户路由过滤规则匹配基础上增加了路由判定信息的判断机制，有效地减少了会话请求被不必要地路由到业务执行点的情况，从而减少业务触发点与业务执行点间的路由冗余。

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

下面说明本发明实施例中的基于分组网络的路由方法的实现。由于

IMS网络是基于分组网络的一种典型系统，本发明实施例即以 IMS网络为例说明本发明实施例提供的技术方案的实现，但不意味着本发明实施例的技术方案仅能用于 IMS网络。在以下实施例中，路由过滤规则可以是用户签约的服务配置（service profile ) 中的 iFC, 网络数据库可以是 HSS。

首先参见图 1 , 图 1是本发明实施例中基于 IMS网络的路由系统的示意图。图 1所示的系统包括：网络数据库，即 HSS、业务执行点和业务触发点。

网络数据库用于存储所有与用户和服务相关的业务数据，包括用户路由过滤规则，将业务数据信息传送给业务触发点。若网络数据库为 HSS并且网络中存在多个可以独立寻址的 HSS , 业务执行点和业务触发点能够利用现有的地址解析机制，找到拥有给定用户身份的订购关系数据的 HSS地址。

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

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

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

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

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

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

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

执行单元，用于根据路由确定单元的确定结果，若确定需要将会话请求路由到业务执行点，则将该会话请求路由至所述业务执行点。

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

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

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

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

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

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

具体地，参见图 2, 本发明实施例一中基于分组网络的路由方法流程图，该流程包括以下步骤：

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

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

若业务执行点所期待被请求的用户列表发生改变，业务执行点可以在 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" encodings "UTF- 8 "?>

<uri-list xmlns:xsi="http：〃 www. w3.org/2001/XMLSchema-instance" xsi:noNamespaceSchemaLocation=''C:\UserProfile\expectant_uri_list.x sd">

<uri-desc change-description:" add"〉

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

</uri-desc>

<uri-desc change-description:" add"〉

</uri-desc>

<uri-desc change-description= " delete" >

</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-OO.txt ) 中有详细说明，这里不再赘述。

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

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

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

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

以上描述的是业务触发点处理的会话请求都是用户主动发送的请求，即处理的是主叫用户的业务。事实上，对于发送给用户的会话请求到达为用户服务的业务触发点后，同样可以利用本发明实施例一，或后续本发明各实施例中基于分组网络的路由方法，处理被叫用户的业务。进一步，对于本实施例一或后续本发明实施例，在业务执行点发送的所期待被请求的用户列表中，还可以给出所期待被请求的 SIP消息内容，即用户列表中除了给出用户标识以外，还可针对每个用户所给出的期待被请求的 SIP消息内容， SIP消息内容可以是 SIP消息中的任意内容，包括 SIP 方式、请求统一资源描述标识符 URI(Uniform Resource Identifier) 、头域或消息体。这样，业务触发点在将用户发送的会话请求路由到业务执行点之前，除了需要进行 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 , 图 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 消息发送至业务触发点，业务触发点将该 Invite消息与用户的 iFC进行匹配，得到对应的无条件前转业务执行点，并进一步判定用户 torn不在无条件前转业务执行点期待被请求的用户列表中，于是，将该会话请求路由到其它期待被请求该用户的业务执行点或者直接路由到被叫方。从实施例一可以看到，由于业务执行点预先将所期待被请求的用户列表发送给业务触发点，这样业务触发点在路由用户请求到业务执行点时根据期待被请求的用户列表增加对该用户的判断，使业务执行点期待的请求才发送到业务执行点，从而减少路由冗余。

实施例二

本实施例中业务执行点预先发送的路由判定信息是用户是否具有业务执行点所期待的标志，具体实现时可采用是否期待的标志即 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" encodings "UTF- 8 "?>

<expectant-requestxmlns:xsi=http：〃 www.w3.org/2001/XMLSchema-in stance

xsi:noNamespaceSchemaLocation=''C:\UserProfile\expectant_request.xsd"> <result uri="tom@home.com">true</result>

</expectant-request>

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

下面参见图 4, 图 4是本发明实施例二中无条件呼叫前转业务的路由流程图，其中，以 IMS网络中用户 tom@home.com的无条件前转业务为例，该流程包括以下步骤：

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

步骤 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是否激活的指示。

本发明实施例中考虑，通过 AS将 DSAI和对应的 iFC同时发送给 HSS, 可以解决 DSAI和 iFC的绑定问题。

参见图 5, 图 5是本发明实施例三中基于分组网络的路由方法流程图，该流程包括以下步骤：

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

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

本实施例三中，业务执行点将 iFC及其是否激活的信息直接发送给了业务触发点，业务触发点根据 iFC和 iFC是否激活的信息判定是否将请求路由到业务执行点。在具体实现中，业务执行点还可以将 iFC及其是否激活的信息发送给 HSS, 此时， HSS根据业务执行点发送的 iFC及其是否激活的信息进一步判断，将不需要绑定激活指示的 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, 分别是 iFCl指示的 ASl和 iFC2指示的 AS2, 且该两个 AS之间存在业务交互关系。为了处理该业务交互，本实施例通过增加一个 iFC3, 用以指示对其中一个 AS的再次调用，需要基于该 AS 已被调用的临时用户数据来执行该再次调用。处理 AS1与 AS2业务交互的流程说明如下：

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

此后，业务触发点收到一个以该用户为被叫的呼入来电，即接收到 SIP INVITE2消息；业务触发点执行 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, Hyper Text Transport Protocol )等。

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

综上所述，以上仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims

权利要求书

1、一种基于分组网络的路由方法，其特征在于，该方法包括：分组网络中的业务触发点获得判定会话请求是否需要被路由到业务执行点的路由判定信息；

2、根据权利要求 1所述的方法，其特征在于，获得所述路由判定信息的步骤包括：

业务触发点接收由业务执行点发送的所述路由判定信息。

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

所述确定是否将会话请求路由到业务执行点的步骤包括：确定所述用户是否是业务执行点所期待被请求的用户。

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

确定用户是否是业务执行点所期待被请求的用户列表中的用户，或者确定用户是否具有业务执行点所期待被请求的用户的标志。

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

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

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

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

7、根据权利要求 6所述的方法，其特征在于，获得所述路由判定信息的步骤进一步包括：

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

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

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

9、根据权利要求 2所述的方法，其特征在于，接收由业务执行点发送的所述路由判定信息的步骤包括：

所述路由判定信息被业务执行点发送的 SIP消息或 Diameter消息携带。

10、根据权利要求 2所述的方法，其特征在于，接收由业务执行点发送的所述路由判定信息的步骤进一步包括：

由业务执行点将路由判定信息发送给网络数据库，业务触发点接收由网络数据库转发的所述路由判定信息。

11、根据权利要求 10所述的方法，其特征在于，所述路由判定信息包括路由过滤规则及与该路由过滤规则绑定的该路由过滤规则是否激活的信息，所述业务触发点接收由网络数据库转发的路由判定信息的步骤包括：

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

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

13、根据权利要求 2所述的方法，其特征在于，该方法进一步包括：所述路由判定信息改变，业务触发点接收业务执行点通知的新的路由判定信息；或者接收业务执行点通知的所改变的路由判定信息。

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

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

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

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

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

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

17、根据权利要求 16所述的方法，其特征在于，所述确定是否将会话请求路由到业务执行点为：确定所述临时用户数据是否存在。

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

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

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

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

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

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