协调不同业务提供者提供的业务的方法和系统的制作方法

专利名称：协调不同业务提供者提供的业务的方法和系统的制作方法
技术领域：
本发明涉及通信领域，尤其涉及协调不同业务提供者提供的业务的技术。 背景技水随着电信业务的蓬勃发展，各运营商逐步由单一的话音运营商向综合信息 运营商进行转型。在向综合信息运营商的转型过程中，运营商迫切需要大量、 并且丰富多样的业务或信息。然而随着业务的发展和深入，业务呈现出越来越 多的特性和复杂度。为了减少整个业务流程体系中业务之间的交互障碍和复杂 度，以及满足人们日益广泛的需求，迫切需要一种技术来规范业务与业务之间 的发现/交互机制。目前业界广泛使用的是提供业务月艮务的OSA/Pariay (Open Mobile Alliance/Parlay)机制，和基于OMA (Open Mobile Alliance,开放移动联盟) 引擎环境提供的OSE机制。所述OSA/Parlay机制的应用体系架构如图l所示，包括Application Server (应用月l务器)、Parlay网关以AAPI (Application Programming Interface,应用 编程接口 )。所述Parlay网关由框架(Framework)和一个或多个业务能力特征 (SCF)组成。其中所述业务能力特征是对网络所提供功能的抽象，所述API 位于应用服务器与Parlay网关之间，通过这个开放、标准的接口，业务开发商、 独立软件提供商(ISV)等可以获得使用现有网络资源的能力，方便、灵活的 开发新业务，从而为客户提供所需要的业务。所述Application Server包括Parlay客户端，由第三方业务供应商或网络运营 商提供，用以开发各种业务，以便提供给终端用户使用。所述Parlay Gateway 包括Parlay服务器，它为Parlay客户端提供各种基本业务能力的支持，使Parlay
客户端的业务能够有控制的、安全的进入到各通信网内。Parlay客户端通过调 用API访问Parlay服务器，它们之间可以采用CORBA、 WEB Service、 JAIN SPA 等分布对象技术进行通信。所述OSE机制是由OMA组织提出的另 一种提供开放业务的技术，其提供分 层的、模块化的、开放的业务生成和执行环境，满足业务快速、有效、低成本 发展的需要。其摒弃原来垂直的业务模型"Silo"，划分业务组成各种引擎(如 呈现，位置，设备管理，彩信等等)，再在OSE的执行环境中进行管理和雇用。 其应用体系架构如图2所示，包括执行环境、各种引擎、策略执行实体和底 层网络资源，所述各种引擎通过I2接口获取底层网络资源，并应用所述底层网 络资源生成业务；所述执行环境通itll接口管理所述各种引擎中的业务；所述 各个引擎还有各自暴露的接口10连接所述策略执行实体，用来获取策略信息， 在执行各个引擎的固有功能之时同时考虑运营商或者终端用户的设定策略。随着OSE技术的发展，众多业界企业开始研究融合重用OSA/Parlay和OSE 二者能力的技术，以便在原有OSA/Parlay技术的基础上，或者在将来部署的业 务网络里，能够兼容OSA/Parlay和OSE两者的能力，为业务开发和业务组合提 供更广泛的基础，提供更统一的封装能力，以便避免重复开发等浪费。另一方 面，OSA/Parlay架构和OSE架构中的业务提供者中所支持的业务能力会存在不 一致的情况，因此若要实现二者的共同配置，必须解决不同的业务提供者能够 对同一业务请求进行处理的问题，以便协调不同业务提供者提供给移动用户的 业务。与本发明有关的现有技术是通过IMS (IP Multimedia System; IP多媒体子 系统)网络里面配置iFC (Initial Filter Criteria;初始过滤规则)来解决不同的 业务提供者能够对同一业务请求进行处理的问题。然而，这种通过配置核心网 的方式不符合业务独立，分层的思想，限制了业务环境的灵活性；同时，复杂 的iFC配置会力。重网络的负担，会导致整个网络处理业务的效率下降。同时， 随着业务的增加，经常修改iFC容易引起网络不稳定，可能埋下巨大隐患。
综上所述，目前迫切需要一种协调不同业务提供者提供给移动用户的业务 的技术。发明内容本发明提供一种协调不同业务提供者提供的业务的方法和系统，通过本发 明，能够使不支持用户所请求的业务中部分功能的业务提供者能够为移动用户 提供其能够支持的其它业务，从而使处于不同架构的不同业务提供者均能够为 用户提供相应的业务，协调了不同业务提供者提供给移动用户的业务。本发明通过如下的技术方案实现本发明提供一种协调不同业务提供者提供的业务的方法，其包括网关业务交换中心GSSC获得发送端的业务请求后，根据接收端的相关业务数据将业务请求转换为接收端所支持的标准形式，然后将所述业务请求传送到所述接收端。其中，所述业务请求包括调用格式，所述根据接收端的相关业务数据将业 务请求转换为接收端所支持的标准形式，然后将所述业务请求传送到所述接收 端的过程，具体包括所述网关业务交换中心GSSC获得发送端业务请求后，根据接收端的相关 业务数据将业务请求中的调用格式转换为接收端所支持的调用格式，然后将所 述业务请求传送到所述接收端。其中，所述业务请求包括业务内容，所述根据接收端的相关业务数据将业 务请求转换为接收端所支持的标准形式，然后将所述业务请求传送到所述接收 端的过程，具体包括所述网关业务交换中心GSSC获得发送端业务请求后，根据接收端的相关 业务数据将业务请求中的业务内容转换为接收端所支持的消息内容，然后将所 述业务请求传送到所述接收端。其中，所述方法还包括
网关业务交换中心GSSC获得发送端的业务请求后，根据业务请求和设定 的策略选择相应的接收端。所支持的消息内容，然后将所述业务请求传送到所述接收端的过程，具体包括业务请求所请求的业务后，将所述业务请求中的内容转换为接收端支持的消息 内容；或，求所请求的业务后，则将所述业务请求传送到所述接收端。 其中，所述的方法还包括所述GSSC获得发送端的业务请求后，根据所述业务请求通过查询的方式 获取到相应的接收端中的相关业务数据；或，所述GSSC中保存有接收端所支持的业务数据，并周期性地从所述接收端 中获取相应的业务数据，并用所获取到的业务数据更新所保存的业务数据。其中，所述的方法还包括发送端发送业务请求到核心网，所述核心网将所述业务请求转发到网关业 务交换中心GSSC。本发明还提供一种协调不同业务提供者提供的业务的系统，其包括 发送端、接收端和网关业务交换中心GSSC;所述GSSC获得发送端的业务请求后，根据接收端的相关业务数据将业务 请求转换为所述接收端所能够支持的标准形式，然后将所述业务请求传送到所 述接收端。其中，所述的系统还包括核心网，用于转发所述发送端发送的业务请求 给所述GSSC;以及，用于转发所述GSSC返回的业务成果给所述发送端。 本发明还提供一种网关业务交换中心GSSC,其包括 信息传输单元和业务交换单元； 所述信息传输单元接收发送端的业务请求，并将其传送给所述业务交换单元；所述业务交换单元获得发送端的业务请求后，根据接收端的相关业务数据 将业务请求转换为所述接收端所能够支持的标准形式，然后将其传送给所述信息传输单元；所述信息传输单元将经过转换处理后的业务请求发送给接收端。 其中，所述的GSSC还包括业务数据获取单元，用于当获得发送端的业务请求后，根据所述业务请求 通过查询的方式获取到相应的接收端中的相关业务数据；或，用于保存有接收端所支持的业务数据，并周期性地从所述接收端中获M目应的业务数据，并用 所获取到的业务数据更新所保存的业务数据。其中，所述业务交换单元还用于当所述GSSC获得发送端的业务请求后， 根据接收端的相关业务数据将业务请求中的调用格式转换为接收端所支持的 调用格式，然后将所述业务请求传送到所述信息传输单元。其中，所述的GSSC还包括策略管理单元和路由确定单元；所述策略管理单元，用于管理设定的策略信息；所述路由确定单元，用于根据所述策略管理单元中的策略信息选择相应的 接收端。关业务数据判断所述接收端是否支持所述业务请求所请求的业务，若确定出所 述接收端不支持所述业务请求所请求的业务后，将所述业务请求中的内容转换 为所述接收端支持的消息内容，然后将所述业务请求传送到所述信息传输单 元；若确定出所述接收端支持所述业务请求中所请求的业务后，则将所述业务 请求传送到所述信息传输单元。由上述本发明提供的技术方案可以看出，本发明中网关业务交换中心 GSSC获得发送端的业务请求后，根据接收端的相关业务数据将业务请求转换 为接收端所支持的标准形式，然后将所述业务请求传送到所述接收端，因此通 过本发明，能够使处于不同架构的不同业务提供者均能够为用户提供相应的业 务，协调了处于不同架构的不同业务提供者为用户提供的业务，例如能够协调基于Parlay和基于OSE技术提供给移动用户的业务的部署和提供，实现了将 已有的Parlay组件配置到近年发展起来的OSE环境中，节省了资源，保护了 运营商的投资。为业务开发提供了更灵活的方式，更丰富的手段。另外，本发明通过GSSC修改业务提供者与上层应用实体间交互信息的调 用格式，为上层应用实体提供了统一接口。


图1为背景技术提供的OSA/Parlay机制的应用体系架构示意图； 图2为背景技术提供的OSE机制的应用体系架构示意图； 图3为本发明提供的第一实施例的流程图；图4为本发明提供的第一实施例中，在作为业务请求者的客户端订阅呈现 业务，并且业务提供者均支持所述呈现业务的情况下的处理流程；图5为本发明提供的第一实施例中，在所述GSSC才艮据业务提供者的所支 持的相关业务数据修改所述SIP请求消息中的相关数据的情况下的处理流程；图6为本发明提供的第二实施例的流程图；图7为本发明提供的第二实施例中，在作为业务请求者的客户端订阅呈现 业务，并且业务提供者不爻持呈现业务中的一些功能的情况下的处理流程； 图8为本发明提供的第三实施例的流程图； 图9为本发明提供的第五实施例的结构原理图； 图IO为本发明提供的第六实施例的结构原理图。
具体实施方式
本发明为了对不同业务提供者提供的业务进行协调，在作为发送端的业务 请求者和作为接收端的业务提供者之间，和/或，在作为发送端的业务提供者与
作为接收端的业务提供者的上层应用实体之间，设置了一种GSSC (Gateway Service Switching Center,网关业务交换中心)。当所述GSSC设置在作为发送端的业务请求者和作为接收端的业务提供者 之间时，由于业务请求者与业务提供者之间所支持的调用格式是相同的，此时 所述GSSC主要用来处理当业务请求者所请求的业务内容与业务提供者所能够 支持的业务内容不一致的情况。当业务请求消息到达所述GSSC后，所述GSSC 根据业务请求者的业务请求消息中的所请求的业务内容，以及其它附带的信 息，比如号段等信息，通过策略的控制选取合适的业务提供者，并根据接收端 的业务数据对不符合所述业务提供者所支持的业务请求进行转换，然后将符合 标准形式的业务请求消息发送给所选择的业务提供者；所述业务提供者返回相 应的业务结果。这样能够在业务提供者提供给移动用户的业务与所述移动用户 所请求的业务中的某些业务功能出现不一致时，继续为所述用户提供所述移动 用户所请求的业务中的其它的业务功能。当业务提供者提供给移动用户的业务 与所述移动用户所请求的业务出现不一致时，所述GSSC也可以不对所述业务 请求进行转换，而直接中止所述业务请求。当所述GSSC设置在作为发送端的业务提供者与作为接收端的业务提供者 的上层应用实体之间时，由于业务提供者与业务提供者的上层应用实体之间所 支持的业务内容一致，并且业务提供者知道上层应用实体采用的服务技术。当 业务提供者与上层应用实体采用不同的服务技术时，二者所支持的调用格式会 存在不同，例如采用OSA7Parlay技术的业务提供者所支持的调用格式为函数 调用格式，而采用OSE技术的上层应用实体所支持的调用格式为消息调用格格式进行转换，然后将符合标准形式的业务请求消息发送给所述上层实体，这 样可以为业务提供者的上层应用实体提供统一的接口 。本发明提供的第一实施例是一种协调不同业务提供者提供的业务的方法， 其核心是GSSC根据接收到的业务请求和设定的策略选择相应的业务提供者， 所述业务请求中所请求的业务，若支持，则将所述业务请求传送到所述业务提供者；若不支持，则根据业务提供者的相关业务数据修改所述业务请求中的消 息内容，并将修改后的业务请求传送到相应的业务提供者。该实施例的具体实 施过程如图3所示，包括如下内容步骤S101,作为发送端的业务请求者发送业务请求到核心网，所述核心网 将所述业务请求转发到网关业务交换中心GSSC。所述请求消息中携带的目的地址为GSSC的地址。所述业务请求中还包含 有业务数据等消息内容，以及业务请求者所使用的号码、业务请求者的优先级 级别和/或负载均衡原则等信息。步骤S102，所述GSSC根据所述业务请求和设定的策略选择相应的业务提 供者作为接收端。所述设定的策略包括号段与业务提供者间的对应原则、优先级级别与业务 提供者间的对应原则和/或负载均衡原则。所述GSSC根据所述业务请求中包含的业务请求者的所使用的号码、业务 请求者的优先级级别和/或负载均衡原则等信息去匹配设定的策略中的信息，如 果匹配到，则按照所匹配到的策略信息对应的原则选择相应的业务提供者作为 接收端。步骤S103,根据业务提供者的相关业务数据判断业务提供者，如Parlay网 关、OSE引擎网关，是否支持所述业务请求中所请求的业务，若支持，则#^亍 步骤S104;若不支持，则执行步骤S105。步骤S104，将所述业务请求传送到所述业务提供者，然后执行步骤S106。步骤S 105 ，根据业务提供者的相关业务数据修改所述业务请求中的相关数 据，并将修改后的业务请求传送到相应的业务提供者，然后执行步骤S106。步骤S105中，当GSSC发现业务提供者不支持业务请求中所请求的业务 后，其会根据业务提供者的相关业务数据对所述业务请求消息中的相关数据进
行修改，使其符合所述业务提供者所支持的消息内容。所述GSSC获取业务提 供者的相关业务数据的方式有两种第一种方式所述GSSC事先保存有业务提供者所支持的业务数据，并周 期性地从所述业务提供者中获取相应的业务数据，并用所获取到的业务^t据更 新所保存的业务数据。第二种方式所述GSSC获得业务请求者的业务请求后，根据所述业务请 求通过查询的方式获取到相应的业务提供者中的相关业务数据。步骤S106，所述业务提供者根据所述业务请求消息中所请求的业务进行相 应的处理，并返回相应的业务成果。当在业务提供者和其上层应用实体间设置有GSSC时，在步骤S106中， 当业务提供者接收到业务请求消息后，可以通过GSSC修改所述业务请求消息 的调用格式，使其符合业务提供者的上层应用实体能够支持的调用格式，然后 再将^f多改后的业务请求消息发送给所述业务提供者的上层应用实体，然后由业 务提供者的上层应用实体提供相应的业务成果。可以看出，业务提供者通过 GSSC这样处理后，其可以为上层应用实体提供统一的接口。当然，在步骤S106中，业务提供者也可以不对业务请求消息的格式进行 修改，但这样，不同业务提供者连接的上层应用实体就不容易做到统一，必须 对上层的业务应用进行修改。步骤S107，所述GSSC将所述业务成果返回给所述业务请求者。在步骤S107中，所述GSSC通过某些消息携带业务成果，在发送所述消 息之前，需要将所述消息的内容修改为所述业务请求者所支持的消息内容，之 后再发送给所述业务请求者。下面以业务请求者的客户端作为发送端订阅呈现业务，并且业务提供者 Parlay网关或OSE引擎网关作为接收端支持所述呈现业务为例对本发明提供 的第一实施例进行详细说明，如图4所示首先，业务请求者的客户端作为发送端，发送订阅呈现业务的SIP请求消
息给核心网SIP/IP Core,所述请求消息中携带的目的地址为GSSC的地址。所 述请求消息中还包括有订阅呈现体(presentity)的信息，触发事件Event为呈 现(Presence)业务等消息内容，以及业务请求所使用的号段信息。随后，所述SIP/IP Core通过SIP订阅请求消息中携带的目的地址将所述 SIP订阅请求消息转发到GSSC。接着，所述GSSC根据业务请求所使用的号码去匹配设定的策略中的号段， 如果匹配到，则根据所述设定的策略中的原则选定一个业务提供者作为接收 端，可以是Pariay网关，也可以是OSE引擎网关。务提供者是否支持所请求的呈现业务，当获知到业务提供者支持所请求的业务 后，则修改所述SIP请求消息携带的目的地址，将所述SIP请求消息发送到所 述业务提供者。所述业务提供者根据所述SIP请求消息返回200 OK的SIP响应消息给所 述GSSC,其中携带着相应的业务成果。所述GSSC返回200 OK的SIP响应消息给所述SIP/IP Core。 所述SIP/IP Core返回200 OK的SIP响应消息给所述客户端。 对于业务提供者不支持业务请求者所请求的业务的处理，主要针对Parlay 架构和OSE架构中所支持的业务数据不一致的情况例如OSE架构中的呈现 业务支持Filtering (过滤)功能，即能够设定接收Presentity (呈现体)等呈现 信息。而早期的Parlay网关不支持这种Filtering (或者其它功能，如Partial Notification, Partial Publication)功能。此时，如果在OSE域的客户端发送订 阅消息订阅要求过滤功能的Parlay呈现业务的信息时，如果Parlay网关不能支 持要求过滤功能的Parlay呈现业务，将会出现业务处理不一致的情况。这时需中的相关数据。具体实现如图5所示，包括业务请求者的客户端作为发送端，发送SIP订阅请求消息；所述SIP订阅 请求消息中携带的目的地址为GSSC的地址。所述业务请求中还包含有业务数 据等消息内容，以及业务请求者所使用的号码、业务请求者的优先级级别和/ 或负栽均衡原则等信息。核心网SIP/IP Core将SIP订阅请求消息发送到GSSC; 所述GSSC根据所述SIP订阅请求消息和设定的策略选定业务提供者为 Parlay网关。具体实现与上述实例中的相关描述雷同，这里不再详细描述。然后所述GSSC根据业务提供者Parlay网关的相关业务数据判断出其不支 持过滤功能，则将SIP请求消息中要求过滤功能的信息去掉，使其达到Parlay 网关所能够支持的消息内容。然后所述GSSC将修改后的SIP订阅请求消息发送给所述Parlay网关； 所述Parlay网关返回200 OK的SIP响应消息给所述GSSC。 所述GSSC返回200OK的SIP响应消息给所述SIP/IP Core。 所述，所述SIP/IP Core返回200OK的SIP响应消息给所述客户端。 本发明提供的第二实施例是另一种协调不同业务提供者提供的业务的方 法，其核心是GSSC根据接收到的业务请求和设定的策略选择相应的业务提 供者作为接收端，然后根据所述业务提供者的相关业务数据判断业务提供者是 否支持所述业务请求中所请求的业务，若支持，则将所述业务请求传送到所述 业务提供者；若不支持，则丟弃所迷业务请求，并返回提供业务失败的信息以 及相应的失败原因值。当业务请求到达作为接收端的业务提供者后，所述业务 提供者根据其上层应用实体所支持的业务数据对所述业务请求中的调用格式 进行修改，使其符合上层应用实体所支持的调用格式，然后发送给所述上层应 用实体，所述上层应用实体与所述业务提供者进行交互共同完成业务提供的任 务。该实施例的具体实施过程如图6所示，包括如下内容步骤S201,作为发送端的业务请求者发送业务请求到核心网，所述核心网 将所述业务请求转发到网关业务交换中心GSSC。所述请求消息中携带的目的地址为GSSC的地址。所述业务请求中还包含
有业务数据等消息内容，以及业务请求者所使用的号码、业务请求者的优先级 级别和/或负载均衡原则等信息。步骤S202，所述GSSC根据所述业务请求和设定的策略选择相应的业务提 供者作为接收端。所述设定的策略中包含的策略信息，以及所述步骤S202的具 体实现与第一实施例中的相关描述雷同，这里不再详细描述。步骤S203,所述GSSC根据所述业务提供者的相关业务数据判断所迷业务 提供者，如Parlay网关、OSE引擎网关，是否支持所述业务请求中所请求的业 务，若支持，则执行步骤S204;若不支持，则执行步骤S205,即丢弃所述业务 请求，并返回提供业务失败的信息以及相应的失败原因值。步骤S204，将所述业务请求传送到所述业务提供者，然后执行步骤S206，步骤S206,所述业务提供者根据所述业务请求消息中所请求的业务进行相 应的处理，并返回相应的业务成果。当在业务提供者和其上层应用实体间设置有GSSC时，在步骤S206中， 当业务提供者接收到业务请求消息后，可以通过GSSC修改所述业务请求消息 的格式，使其符合业务提供者的上层应用实体能够支持的调用格式，然后再将 修改后的业务请求消息发送给所述业务提供者的上层应用实体，然后由业务提 供者的上层应用实体与所述业务提供者进行信息交互，共同完成业务提供的任 务，返回相应的业务成果。可以看出，业务提供者通过GSSC这样处理后，其 可以为上层应用实体提供统一的接口 。当然，在步骤S206中，业务提供者也可以不对业务请求消息的调用格式 进行修改，但这样，不同业务提供者连接的上层应用实体就不容易做到统一， 必须对上层的业务应用进行修改。步骤S207，所述GSSC将所述业务成果返回给所述业务请求者。 在步骤S207中，所述GSSC通过某些消息携带业务成果，在发送所述消 息之前，同样需要将所述消息的内容修改为所述业务请求者所支持的消息内 容，之后再发送给所述业务请求者。 下面以作为业务请求者的客户端订阅呈现业务，并且业务提供者不支持所 述呈现业务中的一些功能为例对本发明提供的第二实施例进行详细说明，如图7所示业务请求者的客户端作为发送端，发送SIP订阅请求消息，所述SIP订阅请 求消息携带要求订阅过滤功能的呈现业务；核心网SIP/IP Core将SIP订阅请求消息发送到GSSC;所述GSSC根据设定的策略选定业务提供者为Parlay网关；然后所述GSSC根据业务提供者Parlay网关的相关业务数据判断出其不支 持过滤功能，则丢弃所述SIP订阅请求消息，并返回提供业务失败的信息以及 相应的失败原因值给所述SIP/IP Core。所述SIP/IP Core返回提供业务失败的信息以及相应的失败原因值给所述 客户端。本发明提供的第三实施例是第三种协调不同业务提供者提供的业务的方 法，其核心是所述网关业务交换中心GSSC获得作为发送端的业务提供者的业务请求转换为业务提供者的上层应用实体所支持的调用格式，然后将所述业 务请求传送到所述业务提供者的上层应用实体。该实施例的具体实施过程如图 8所示，包括如下内容步骤S301，当作为发送端的业务提供者接收到业务请求后，将所述业务请 求发送给GSSC。步骤S302，所述GSSC根据业务提供者的上层应用实体的相关业务数据修 改所述业务请求中的调用格式，并将修改后的业务请求传送到相应的上层应用 实体。例如如果所述上层应用实体是采用OSE技术的应用实体，而业务提供者为 采用OSA/Parlay技术的Parlay网关，则需将业务请求消息中的Parlay网关所支持 的调用格式转换为上层应用实体所支持的调用格式。
以呈现业务的订阅功能为例，如某Parlay网关的函数调用格式为 SubscribePresence(SbuscribePresenceRequest, SubscribeResponse) 其中，请求消息SbuscribePresenceRequest包含以下两个参数 Presentity(xsd: anyURl) Attributes (PresenceAttributeiype)转换为消息调用格式后得到的OSE的呈现业务的订阅功能的业务请求如下:SUBSCRIBE sip:user2@soho.com SIP/2.0Via: SIP/2.0/UDPuserl,huawei.com;branch=z9hG4bRnashds7Max-Forwards: 70From: <sip:userl@ soho.com>;tag=31415 To: <sip:user2@ soho.com> Call-ID: b89rjhned,slj40a222 CSeq: 61 SUBSCRIBE Event: presence Expires: 7200Accept: application/pidf+xmlContact: userl. soho.comContent-Type: application/simple-filter+xmlContent-Length:...其中，Presentity(xsd:anyURI)对应OSE呈现订阅消息的<sip:user2@ soho.com> )，用来提供呈现业务被订阅者的地址，Attributes (PresenceAttributeType)对应OSE中呈现订阅消息中Content-Type: application/simple-filter+xml ，用来指定订阅的Presence信息的类型。步骤S302中，所述GSSC获取业务提供者的上层应用实体的相关业务数 据的方式有两种第一种方式所述GSSC事先保存有业务提供者的上层应用实体所支持的 业务数据，
据，并用所获取到的业务数据更新所保存的业务数据。第二种方式所述GSSC获得作为发送端的业务提供者的业务请求后，根 据所述业务请求通过查询的方式获取到相应的业务提供者的上层应用实体中 的相关业务数据。步骤S303，所述上层应用实体获得所述业务请求后，与所述业务提供者进 行信息交互，完成业务提供的任务，然后将所述业务成果返回给所述GSSC。 步骤S304,所述GSSC将所述业务成果返回给所述作为发送端的业务提供者。在步骤S304中，所述GSSC通过某些消息携带业务成果，在发送所述消 息之前，需要将所述消息的调用格式修改为所述业务请求者所支持的调用格 式，之后再发送给作为发送端的业务提供者。本发明提供的笫四实施例是一种协调不同业务提供者提供的业务的系统， 其包括发送端、接收端和网关业务交换中心GSSC。所述GSSC获得发送端的 业务请求后，根据接收端的相关业务数据将业务请求转换为所述接收端所能够 支持的标准形式，然后将所述业务请求传送到所述接收端；当所述接收端根据 所述业务请求提供相应的业务成果后，所述GSSC将所述业务成果发送给所述 发送端。当发送端为业务请求者、接收端为业务提供者时，所述系统还包括核心网， 用于转发所述作为发送端的业务请求者发送的业务请求给所述GSSC;以及， 用于转发所述GSSC返回的业务成果给所述业务请求者。在这种情况下，系统 者的各个元器件间的信号传递关系如下作为发送端的业务请求者发送业务请求消息到核心网后，所述核心网通过 其内的核心部件将所述业务请求消息转发到所述GSSC;所述GSSC获得业务请求者的业务请求后，根据设定的策略选定相应的业务提供者是否支持所述业务请求中所请求的业务中的功能，如果支持，则将所
述业务请求消息转发到所述业务提供者。具体实施过程与本发明提供的第 一实 施例中的相关描述雷同，这里不再详细描述。功能，则采取两种措施转换所述业务请求第一种修改接收到的业务请求消息中的内容，将所述业务请求消息中业 务提供者不支持的业务功能去掉，然后将修改后的业务请求消息传送到相应的 业务提供者。具体实施过程与本发明提供的第一实施例中的相关描述雷同，这 里不再详细描述。第二种直接丟弃所迷业务请求消息，并返回提供业务失败的信息以及失 败原因值。具体实施过程与本发明提供的第二实施例中的相关描述雷同，这里 不再详细描述。所述GSSC将所述业务成果发送给业务请求者。当发送端为业务提供者，接收端为业务提供者的上层应用实体时，所述系 统中的各个元器件间的信号传递关系如下当作为发送端的业务提供者接收到业务请求后，将其发送给所述GSSC;所述GSSC根据业务提供者的上层应用实体的相关业务数据修改所述业务 请求中的调用格式，并将修改后的业务请求传送到相应的上层应用实体。所述 GSSC获取上层应用实体的相关业务数据的处理过程与第三实施例中的相关描 述雷同，这里不再详细描述。所述上层应用实体获得所述业务请求后，与所述业务提供者进行信息交 互，完成业务提供的任务，然后将所述业务成果返回给所述GSSC。所述GSSC将所述业务成果返回给作为发送端的业务提供者。这一部分的 具体实施过程与第一实施例中的相关描述雷同，这里不再详细描述。本发明提供的第五实施例是一种网关业务交换中心GSSC，其结构如图9 所示，包括业务交换单元和信息传输单元；当所述GSSC中没有业务提供者所 支持的业务数据信息时，所述GSSC中还包括业务数据获取单元。 所述业务数据获取单元保存有作为接收端的业务提供者的上层应用实体 所支持的业务数据，并周期性地从所述接收端中获取相应的业务数据，并用所获取到的业务数据更新所保存的业务数据。或者，当业务请求到达所述GSSC 后，所述GSSC通过所述业务数据获取单元根据所述业务请求通过查询的方式 获取到相应的接收端中的相关业务数据。当作为发送端的业务提供者的业务请求到达GSSC后，所述信息传输单元 接收到后，将其传递给所述业务交换单元。所述业务请求，使其符合所述业务提供者的上层应用实体所支持的调用格式， 并将修改后的业务请求传送到所述业务提供者的上层应用实体。所述GSSC的 具体处理过程与本发明提供的第三实施例中的相关描述雷同，这里不再详细描述。所述业务提供者的上层应用实体根据接收到的业务请求与作为发送端的 业务提供者进行交互，并根据交互信息提供相应的业务成果，并将所述业务成 果返回给所述GSSC;所述GSSC通过业务交换单元对携带所述业务成果的消息的调用格式进行 修改，使其能够符合所述所述作为发送端的业务提供者所能够支持的调用格 式，然后通过所述信息传输单元将其发送出去。本发明提供的第六实施例是一种网关业务交换中心GSSC，其结构如图10 所示，包括策略管理单元、路由确定单元、业务交换单元和信息传输单元。当 所述GSSC中没有业务提供者所支持的业务数据信息时，所述GSSC中还包括 业务数据获取单元。所述策略管理单元管理一些设定的策略信息；所迷i殳定的策略信息的详细 描述与第一实施例中的相关描述雷同，这里不再详细描述。据，并周期性地从所述接收端中获糾目应的业务数据，并用所获取到的业务数
据更新所保存的业务数据。或者，当业务请求到达所述GSSC后，所迷业务数 据获取单元4艮据所述业务请求，通过查询的方式获取到相应的作为接收端的业 务提供者中的相关业务数据。当业务请求到达所述GSSC后，所述路由确定单元根据所述策略管理单元中的策略信息选定相应的业务提供者作为接收端；然后将所选定的业务提供者 告知所述业务交换单元。的业务，若支持，则将所述业务请求传送到所述业务提供者；若不支持，则根 据所述业务提供者的业务数据修改所述业务请求的内容，使其符合所述业务提 供者所支持的消息内容，并将修改后的业务请求传送到所述业务提供者。所述 GSSC的具体处理过程与本发明提供的第一实施例中的相关描述雷同，这里不 再详细描述。所述业务提供者根据接收到的业务请求提供相应的业务成果，并将所述业 务成果返回给所述GSSC;所述GSSC通过所述业务交换单元将携带所述业务成果的消息的内容进行 修改，使其能够符合所述所述作为发送端的业务请求者所能够支持的消息内 容，然后将其发送出去。上述一些处理过程中是以呈现业务为例进行说明的，但本发明不限于仅仅 应用呈现业务，本发明还可以应用于任何Parlay和OSE提供的业务如位置业 务Location,策略业务Policy等。而且，本发明不局限于应用到OSA/Parlay 和OSE这两种技术共存的系统中，还可以应用于解决其它系统中具有不同业 务提供能力的业务提供者中遇到的同样问题，例如ParlayX系统。由上述本发明提供的具体实施方案可以看出，本发明中网关业务交换中心 GSSC获得业务请求者的业务请求后，根据设定的策略以及业务提供者的相关 业务数据根据需要进行转换并确定相应的业务提供者，然后将所述业务请求传 送到所述业务提供者，因此通过本发明，能够协调不同业务提供者提供给移动
用户的业务，例如能够协调基于Parlay和基于OSE技术提供给移动用户的业务 的部署和提供，实现了将已有的Parlay组件配置到近年发展起来的OSE环境中， 也可保护已往开发的应用运用新的引擎，节省了资源，保护了运营商的投资。 为业务开发提供了更灵活的方式，更丰富的手段。另外，本发明通过GSSC修改相应的业务请求消息，能够防止提供给移动 用户的业务出现不一致的现象发生。显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发 明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及 其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
权利要求
1、一种协调不同业务提供者提供的业务的方法，其特征在于，包括网关业务交换中心GSSC获得发送端的业务请求后，根据接收端的相关业务数据将业务请求转换为接收端所支持的标准形式，然后将所述业务请求传送到所述接收端。
2、 如权利要求l所述的方法，其特征在于，所述业务请求包括调用格式，然后将所述业务请求传送到所述接收端的过程，具体包括所述网关业务交换中心GSSC根据接收端的相关业务数据将业务请求中的 调用格式转换为接收端所支持的调用格式，然后将所述业务请求传送到所述接 收端。
3、 如权利要求l所述的方法，其特征在于，所述业务请求包括业务内容，然后将所述业务请求传送到所述接收端的过程，具体包括所述网关业务交换中心GSSC根据接收端的相关业务数据将业务请求中的 内容转换为接收端所支持的消息内容，然后将所述业务请求传送到所述接收 端。
4、 如权利要求3所述的方法，其特征在于，还包括 网关业务交换中心GSSC获得发送端的业务请求后，根据业务请求和设定的策略选择相应的接收端。
5、 如权利要求3所述的方法，其特征在于，所述根据接收端的相关业务 数据将业务请求中的内容转换为接收端所支持的消息内容，然后将所述业务请 求传送到所述接收端的过程，具体包括业务请求所请求的业务，若确定出所述接收端不支持所述业务请求所请求的业 务后，将所述业务请求中的内容转换为接收端支持的消息内容，然后将所述业 务请求传送到所述接收端；或， GSSC所请求的业务后，若确定出所述接收端支持所述业务请求中所请求的业务后， 则将所述业务请求传送到所述接收端。
6、 如权利要求1至5任意一项所述的方法，其特征在于，还包括所述GSSC获得发送端的业务请求后，根据所述业务请求通过查询的方式 获取到相应的接收端中的相关业务数据；或，所述GSSC中保存有接收端所支持的业务数据，并周期性地从所述接收端 中获M目应的业务数据，并用所获取到的业务数据更新所保存的业务数据。
7、 如权利要求6所述的方法，其特征在于，还包括 发送端发送业务请求到核心网，所述核心网将所述业务请求转发到网关业务交换中心GSSC。
8、 一种协调不同业务提供者提供的业务的系统，其特征在于，包括 发送端、接收端和网关业务交换中心GSSC;所述GSSC用于获得发送端的业务请求后，根据接收端的相关业务数据将 业务请求转换为所述接收端所能够支持的标准形式，然后将所述业务请求传送 到所述接收端。
9、 如权利要求8所述的系统，其特征在于，还包括核心网，用于转发 所述发送端发送的业务请求给所述GSSC;以及，用于转发所述GSSC返回的 业务成果给所述发送端。
10、 一种网关业务交换中心GSSC,其特征在于，包括 信息传输单元和业务交换单元；所述信息传输单元用于接收发送端的业务请求，并将其传送给所述业务交 换单元；所述业务交换单元获得发送端的业务请求后，根据接收端的相关业务 数据将业务请求转换为所述接收端所能够支持的标准形式，然后将其传送给所 述信息传输单元；所述信息传输单元将经过转换处理后的业务请求发送给接收端。
11、 如权利要求10所述的GSSC，其特征在于，还包括 业务数据获取单元，用于当获得发送端的业务请求后，根据所述业务请求通过查询的方式获取到相应的接收端中的相关业务数据；或，用于保存有接收 端所支持的业务数据，并周期性地从所述接收端中获糾目应的业务数据，并用 所获取到的业务数据更新所保存的业务数据。
12、 如权利要求10或11所述的GSSC,其特征在于，所述业务交换单元 还用于当所述GSSC获得发送端的业务请求后，根据接收端的相关业务数据将业务请求中的调用格式转换为接收端所支持的调用格式，然后将所述业务请求 传送到所述信息传输单元(
13、 如权利要求10或11所述的GSSC,其特征在于，还包括 策略管理单元和路由确定单元；所述策略管理单元，用于管理设定的策略信息；所述路由确定单元，用于根据所述策略管理单元中的策略信息选择相应的 接收端。
14、 如权利要求13所述的GSSC，其特征在于，所述业务交换单元还用于 根据所述路由确定单元选择的接收端的相关业务数据判断所述接收端是否支 持所迷业务请求所请求的业务，若确定出所述接收端不支持所述业务请求所请 求的业务后，将所述业务请求中的内容转换为所述接收端支持的消息内容，然 后将所述业务请求传送到所述信息传输单元；若确定出所述接收端支持所述业 务请求中所请求的业务后，则将所述业务请求传送到所述信息传输单元。
全文摘要
本发明公开了一种协调不同业务提供者提供的业务的方法和系统，其核心是网关业务交换中心GSSC获得发送端的业务请求后，根据接收端的相关业务数据将业务请求转换为接收端所支持的标准形式，然后将所述业务请求传送到所述接收端；当所述接收端根据所述业务请求提供相应的业务成果后，所述GSSC将所述业务成果发送给所述发送端。通过本发明，能够在业务提供者提供给移动用户的业务与所述移动用户所请求的业务出现不一致时，继续为所述用户提供其它的业务，从而协调了不同业务提供者提供给移动用户的业务，实现了将已有的Parlay组件配置到近年发展起来的OSE环境中。另外，本发明能够为上层应用实体提供了统一接口。
文档编号H04L12/66GK101163120SQ200610140900
公开日2008年4月16日 申请日期2006年10月13日 优先权日2006年10月13日
发明者扬 招, 潘秋菱 申请人:华为技术有限公司