CN100456730C - 一种实现跨智能平台业务切换的方法和装置 - Google Patents

Abstract

本发明公开了一种实现跨智能平台业务切换的方法，该方法包括：服务连接实体向第一智能平台发送请求智能服务的消息；第一智能平台判断所请求的智能服务是否应该由自身处理，如果是，则与服务连接实体进行后续交互完成智能服务，然后结束本次流程，否则，将请求智能服务的消息转发到第二智能平台；第二智能平台与服务连接实体进行后续交互完成智能服务。本发明还提供了一种实现跨智能平台业务切换的装置。采用本发明所提供的高效和通用的特点。

Description

一种实现跨智能平台业务切换的方法和装置

技术领域

本发明涉及智能网技术，特别是涉及一种实现跨智能平台业务切换的方法和装置。

背景技术

随着智能网业务的快速发展，仅靠一个智能平台来提供某种业务已经不能满足需要。而如果引入多个智能平台提供不同的业务，就需要解决新旧平台上的业务融合问题。

例如，虚拟专用网(VPN，Virtual Private Network)业务所涵盖的用户，服务费用由公司支付；而个人用户通常采取预付费业务(PPS，PrepaidService)的形式，费用由用户自己支付。但是，为了使VPN业务更能够适应大公司的结构，能够覆盖公司中不同类型的成员，就需要VPN业务所涵盖的用户也可以使用PPS业务，也就是说，公司可以规定一个范围，个人所使用的业务如果在此范围之内则由公司支付费用，而如果在此范围之外则由个人支付费用。但是，对于VPN业务所涵盖的用户，其请求服务的消息全部都被发送到VPN平台。这样就涉及到提供VPN业务的智能平台和提供PPS业务的智能平台之间的业务切换问题。

这种业务切换目前并没有标准的国际规范遵从。这样，在现有技术中，智能平台间的业务切换是由一个智能平台调用另一个智能平台的业务的方法来完成的。这种调用是通过智能平台间自定义接口进行的。但是，在实际操作中，这种方法存在很大的局限性。首先，不同的智能平台往往由不同的厂家生产，为了实现彼此之间的业务切换，需要两个厂家开放自己平台，并在开发产品的过程中协商具体调用接口，这在现实中往往是不可行的。其次，即使实现了两个智能平台间的接口，由一个智能平台调用另一个智能平台的业务，这种做法的效率比较低下。例如VPN平台调用PPS平台业务，需要周期性的向PPS业务平台申请费用，效率低下的同时对于承载网络的要求却很高。

因此，现有技术无法高效率的实现跨智能平台间的业务实现。

发明内容

有鉴于此，本发明的主要目的在于提供一种实现跨智能平台业务切换的方法，以通过简单的操作，高效率的实现智能平台间的业务切换。

有鉴于此，本发明的主要目的还在于提供一种实现跨智能平台业务切换的装置，在判断出所请求的智能服务不应该由自身处理时，将业务切换到除自身以外的其他智能平台。

为了达到上述目的，本发明提供了一种实现跨智能平台业务切换的方法，包括：

服务连接实体向第一智能平台发送请求智能服务的消息；

第一智能平台判断所请求的智能服务是否应该由自身处理，如果是，则与服务连接实体进行后续交互完成智能服务，然后结束本次流程，否则，将请求智能服务的消息进行重组后转发到第二智能平台；

第二智能平台与服务连接实体进行后续交互完成智能服务。

其中，所述服务连接实体向第一智能平台发送请求智能服务的消息为：

服务连接实体将请求智能服务的消息，封装在第一开始信令中发送到信令网上，第一开始信令的源地址是服务连接实体的地址，第一开始信令的目的地址是第一智能平台的地址。

其中，所述第一智能平台将请求智能服务的消息转发到第二智能平台为：

第一智能平台将请求智能服务的消息封装在第二开始信令中发送到信令网上，第二开始信令的源地址是服务连接实体的地址，第二开始信令的目的地址是第二智能平台的地址。

其中，所述第二智能平台与服务连接实体进行后续交互完成智能服务包括：

第二智能平台从信令网上接收请求智能服务的消息，并根据所接收的消息确定响应消息的内容；

第二智能平台将响应消息封装在继续信令中发送到信令网上，继续信令的源地址是第二智能平台的地址，继续信令的目的地址是服务连接实体的地址；

服务连接实体从信令网上接收第二智能平台所发出的响应消息，并根据重定向路由功能处理响应消息；

服务连接实体和第二智能平台直接进行后续交互，完成智能服务。

其中，所述服务连接实体为移动交换中心/业务交换点，或，服务性通用分组无线业务支撑节点。

其中，所述请求智能服务的消息为移动网增强逻辑的客户化应用CAMEL协议的初始探测点程序IDP消息。

其中，所述开始信令是事务处理能力应用部分TCAP协议的开始TO_BEGIN信令。

其中，所述继续信令是TCAP协议的继续TO_CONTINUE信令。

其中，所述第一智能平台为虚拟专用网平台，所述第二智能平台为预付费业务平台。

为了达到上述目的，本发明还提供了一种实现跨智能平台业务切换的业务控制点，包括用于收发信令的信令接入单元以及用于处理信令的业务控制单元，并且与智能业务模块相连，所述业务控制单元进一步包括：

智能服务请求消息分析模块，用于从信令接入单元所收到的信令中提取智能服务请求消息，并根据所述智能服务请求消息判断所请求的智能服务是否应该由与自身对应的业务控制点处理，并且根据判断结果将所述智能服务请求消息发送给智能业务模块或者智能服务请求消息重组模块；

智能服务请求消息重组模块，用于将智能服务请求消息分析模块发来的智能服务请求消息重组后发送给信令接入单元。

采用本发明所提供的技术方案，第一智能平台收到请求智能业务的消息，仍然会判断该业务是否应该由第二智能平台处理，如果是则将该消息转发给第二智能平台，由第二智能平台与智能业务的请求者进行后续的交互。第一智能平台在转发消息给第二智能平台时是通过7号信令网，而7号信令网是通用的接口，这样就无需第一智能平台和第二智能平台之间定义专门的接口；后续的交互是由第二智能平台直接与智能业务的请求者交互，而不需要经过第一智能平台调用，这样就提高了效率。

附图说明

图1是跨智能平台进行业务切换的系统示意图；

图2是本发明所提供的实现跨智能平台业务切换的方法实施例一的流程图；

图3是本发明所提供的实现跨智能平台业务切换的方法实施例一的信令图；

图4是本发明所提供的实现跨智能平台业务切换的方法实施例二的信令图；

图5是本发明所提供的实现跨智能平台业务切换的方法实施例三的信令图；

图6是本发明所提供的实现跨智能平台业务切换的装置的方框图。

具体实施方式

本发明的核心思想在于：第一智能平台在需要第二智能平台处理用户所请求的智能服务时，将用户请求智能服务的消息，利用标准的7号信令系统，转发到第二智能平台，并且由第二智能平台与用户进行后续交互以完成智能服务。

为使本发明的目的、技术方案和优点更加清楚，下面结合附图及具体实施例对本发明作进一步地详细描述。

请参考图1，图1是跨智能平台进行业务切换的系统示意图。在图1中，以第一智能平台是VPN平台，第二智能平台是PPS平台为例。图中仅仅给出了智能平台中与本发明特别相关的模块，即对于VPN平台来说，是VPN业务控制点(SCP，Service Control Point)，对于PPS平台来说，是PPS SCP。需要说明的是，本发明针对的是第一智能平台和第二智能平台不在同一物理实体内的情况。因为如果第一智能平台和第二智能平台位于同一物理实体内，就不用考虑平台之间的接口问题了。另外，在本实施例中，用户所请求的智能服务是基于传统的话音业务的智能服务。

请参考图2，图2是本发明所提供的实现跨智能平台业务切换的方法实施例一的流程图。本实施例针对的是图1所示的系统。该方法包括以下步骤：

步骤201：用户向移动交换中心(MSC，Mobile Switching Center)/业务交换点(SSP，Service Switching Point)发起呼叫。

MSC与SSP互相配合以接收用户的呼叫，并且为用户建立通信。

步骤202：MSC/SSP将IDP消息发送到VPN的SCP上。

MSC/SSP接收到用户呼叫后，总是会向智能平台发出实现智能业务的第一条消息，这条消息称为初始探测点程序(IDP，Initial Detect-pointProcedure)消息。IDP消息也可以看作是MSC/SSP向智能平台发出的请求智能服务的消息。

IDP消息属于移动网增强逻辑的客户化应用(CAMEL，CustomizedApplication for Mobile network Enhanced Logic)协议层。IDP消息是被封装在事务处理能力应用部分(TCAP，Transaction Capabilities Application Part)层的特定信令中，通过7号信令网进行发送的。从协议栈的角度来看，TCAP层比CAMEL层更靠近物理层，也就是更靠近协议栈的底层。MSC/SSP向SCP发送的IDP消息封装在TCAP层的开始(TO_BEGIN)信令中。TCAPTO_BEGIN信令中至少携带有两个参数，分别表示IDP消息的源地址与目的地址。

对于VPN所涵盖的用户来说，所发出的IDP消息总是会被MSC/SSP发送到VPN的SCP上。因此，在封装有MSC/SSP向SCP发送的IDP消息的TCAP TO_BEGIN信令中，源地址是MSC/SSP，目的地址是VPN的SCP。

步骤203：VPN的SCP判断本次呼叫是否应该由PPS的SCP处理，如果是则执行步骤205，否则执行步骤204，

事实上，SCP内部分为信令接入单元(SAU，Signal Access Unit)和业务控制单元(SCU，Service Control Unit)两部分。SAU负责信令的接收和发送，SCU负责对接收到的信令进行处理，以及确定所要发送的信令。

因此，MSC/SSP所发送的IDP消息，实际上是由VPN的SCP上的SAU接收后交给VPN的SCP上的SCU处理的；由VPN的SCP上的SCU根据IDP消息中的参数判断本次请求是否应该由PPS的SCP处理。

所述IDP消息中的参数应该是表示呼叫种类的参数，例如，可以表示本次呼叫是本地电话、国内长途还是国际长途的被叫号码参数。在VPN上存有预先设定的应该由VPN的SCP处理的业务种类。在接收到IDP消息并识别出该IDP消息所请求的业务种类后，VPN的SCU结合预先设定的应该由VPN的SCP处理的业务种类，判断本次呼叫是否应该由PPS的SCP处理。

步骤204：VPN的SCP处理本次服务请求，然后结束本次流程。

VPN的SCP与MSC/SSP交互完成本次智能服务。

步骤205：VPN的SCP中的SCU将TCAP TO_BEGIN信令中的目的地址改为PPS的SCP地址，源地址不变。

步骤206：VPN的SCP中的SAU将新的TCAP TO_BEGIN信令发送到信令网上。

步骤207：PPS的SCP从信令网上接收到VPN的SCP所发出的TCAPTO_BEGIN信令。

步骤208：PPS的SCP向MSC/SSP发送响应消息。

对于PPS的SCP来说，在其接收到的TCAP TO_BEGIN信令中，目的地址为自身，而源地址为MSC/SSP，这与由MSC/SSP直接发来的TCAPTO_BEGIN信令没有区别。因此，PPS的SCP会认为TCAP TO_BEGIN所封装的IDP消息就是MSC/SSP发给自己的服务请求。PPS的SCP根据该IDP消息确定向MSC/SSP发送的响应内容，然后封装在TCAP继续(TO_CONTINUE)信令中发送到信令网上。TCAP TO_CONTINUE信令中的地址参数表示该信令目的地址是MSC/SSP，而源地址是PPS的SCP。

步骤209：MSC/SSP根据TCAP层的重定向路由功能处理响应消息。

MSC/SSP在接收到PPS的SCP所发来的TCAP TO_CONTINUE信令后，会根据信令中的地址参数判断出该信令的源地址与自身所发送的TCAPTO_BEGIN信令中的目的地址不一致。对于这种不一致，MSC/SSP会根据TCAP层的重定向路由功能进行处理。重定向路由功能是由TCAP协议规定的。简单的说，当网络中的第一实体向第二实体发送请求后，却接收到第三实体发来的针对所发送请求的响应，这时候第一实体比较之前发送的请求和接收到的响应的关联性，以决定下一步操作是丢弃该响应还是直接与第三实体进行后续交互。在本实施例中，经过处理后，MSC/SSP认为接下来的交互需要与PPS的SCP进行，而不再与VPN的SCP进行。

步骤210：MSC/SSP与PPS的SCP交互，完成本次智能服务。

这样，在后续的交互中，就不再需要VPN的SCP参与了。

以上实施例所针对的是基于传统的话音业务的智能服务的情况，基于短消息的智能服务属于基于传统的话音业务的智能服务的一种。而基于数据的智能服务是另外一种情况。对于基于数据的智能服务而言，接收用户所发起的请求并发送到VPN的SSP上的任务不是由MSC/SSP，而是由服务性通用分组无线业务支撑节点(SGSN，Serving General packet radio serviceSupporting Node)来完成的。由于MSC/SSP和SGSN的作用都是在用户和智能平台之间进行连接，因此MSC/SSP和SGSN可以统称为服务连接实体。

对于基于传统的话音业务的智能服务，基于短消息的智能服务以及基于数据的智能服务这三种情况下，智能网络中各实体间的交互详细信令请参见图3到图5。在每幅图的左侧所标的序号即为该组信令所对应的图2中的步骤。可以看出，在用户刚发起智能服务流程的时候，封装了IDP消息的开始信令是由VPN的SCP处理的，但是当VPN的SCP判断出此次智能服务应该由PPS的SCP处理，并将封装了IDP消息的开始信令转发给PPS的SCP之后，VPN的SCP就不再参与后续的交互，而是由PPS的SCP与MSC进行交互。

为了实现本发明所提供的实现跨智能平台业务切换的方法，需要在第一智能平台，即VPN的SCP中增加相应的功能模块。请参考图6，图6是本发明提供的实现跨智能平台业务切换的SCP的方框图。本发明所提供的SCP包括：

SAU：用于从信令网接收信令并发送给SCU处理；还用于将SCU所要发送的信令发送到信令网上。

SCU：用于处理信令，包括智能服务请求消息分析模块、智能业务模块以及智能服务请求消息重组模块。

智能服务请求消息分析模块：用于从SAU发来的信令中提取智能服务请求消息，并判断所述智能服务请求消息所请求的智能服务是否应该由本SCP处理，然后根据结果将智能服务请求消息转发给智能业务模块或者智能服务请求消息重组模块。

具体的说，如果所述智能服务请求消息所请求的智能服务应该由本SCP处理，则智能服务请求消息分析模块将所述智能服务请求消息发送给智能业务模块；如果所述智能服务请求消息所请求的智能服务不应该由本SCP处理，则智能服务请求消息分析模块进一步根据事先的记录判断应该由哪个SCP处理所述智能服务，然后将所述智能服务请求消息以及应该处理所述智能服务的SCP地址发送给智能服务请求消息重组模块。

智能业务模块：用于通过SAU与服务连接实体进行交互完成智能服务。需要说明的是，在图6中，智能业务模块是SCU的一部分，但是在实际中，智能业务模块可能不在SCU中，甚至可能不在SCP中。也就是说，智能业务模块不是本发明所提供的SCP的必要组成模块。同时，智能业务模块的具体实现也与现有技术一样。

智能服务请求消息重组模块：用于根据智能服务请求消息分析模块发来的智能服务请求消息以及SCP地址，构造新的智能服务请求消息，并通过SAU发送到信令网上。

具体的说，智能服务请求消息重组模块将所述智能服务请求消息的目的地址修改为智能服务请求消息分析模块发来的SCP地址，然后发送给SAU。

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

Claims (10)

1、一种实现跨智能平台业务切换的方法，其特征在于，该方法包括：

服务连接实体向第一智能平台发送请求智能服务的消息；

第一智能平台判断所请求的智能服务是否应该由自身处理，如果是，则与服务连接实体进行后续交互完成智能服务，然后结束本次流程，否则，将请求智能服务的消息进行重组后转发到第二智能平台；

第二智能平台与服务连接实体进行后续交互完成智能服务。

2、根据权利要求1所述的实现跨智能平台业务切换的方法，其特征在于，所述服务连接实体向第一智能平台发送请求智能服务的消息为：

服务连接实体将请求智能服务的消息，封装在第一开始信令中发送到信令网上，第一开始信令的源地址是服务连接实体的地址，第一开始信令的目的地址是第一智能平台的地址。

3、根据权利要求1所述的实现跨智能平台业务切换的方法，其特征在于，所述第一智能平台将请求智能服务的消息转发到第二智能平台为：

第一智能平台将请求智能服务的消息封装在第二开始信令中发送到信令网上，第二开始信令的源地址是服务连接实体的地址，第二开始信令的目的地址是第二智能平台的地址。

4、根据权利要求1所述的实现跨智能平台业务切换的方法，其特征在于，所述第二智能平台与服务连接实体进行后续交互完成智能服务包括：

第二智能平台从信令网上接收请求智能服务的消息，并根据所接收的消息确定响应消息的内容；

第二智能平台将响应消息封装在继续信令中发送到信令网上，继续信令的源地址是第二智能平台的地址，继续信令的目的地址是服务连接实体的地址；

服务连接实体从信令网上接收第二智能平台所发出的响应消息，并根据重定向路由功能处理响应消息；

服务连接实体和第二智能平台直接进行后续交互，完成智能服务。

5、根据权利要求1至4任一项所述的实现跨智能平台业务切换的方法，其特征在于，所述服务连接实体为移动交换中心/业务交换点，或，服务性通用分组无线业务支撑节点。

6、根据权利要求1至4任一项所述的实现跨智能平台业务切换的方法，其特征在于，所述请求智能服务的消息为移动网增强逻辑的客户化应用CAMEL协议的初始探测点程序IDP消息。

7、根据权利要求2或3所述的实现跨智能平台业务切换的方法，其特征在于，所述开始信令是事务处理能力应用部分TCAP协议的开始TO_BEGIN信令。

8、根据权利要求4所述的实现跨智能平台业务切换的方法，其特征在于，所述继续信令是TCAP协议的继续TO_CONTINUE信令。

9、根据权利要求1所述的实现跨智能平台业务切换的方法，其特征在于，所述第一智能平台为虚拟专用网平台，所述第二智能平台为预付费业务平台。

10、一种实现跨智能平台业务切换的业务控制点，包括用于收发信令的信令接入单元以及用于处理信令的业务控制单元，并且与智能业务模块相连，其特征在于，所述业务控制单元进一步包括：

智能服务请求消息分析模块，用于从信令接入单元所收到的信令中提取智能服务请求消息，并根据所述智能服务请求消息判断所请求的智能服务是否应该由与自身对应的业务控制点处理，并且根据判断结果将所述智能服务请求消息发送给智能业务模块或者智能服务请求消息重组模块；

智能服务请求消息重组模块，用于将智能服务请求消息分析模块发来的智能服务请求消息重组后发送给信令接入单元。

Images