CN102118535B - 一种业务嵌套的实现方法、多业务控制器和交换设备 - Google Patents

Abstract

本发明实施例提供一种多业务嵌套的实现方法、多业务控制器和交换设备，该方法包括：多业务控制器接收到用户发起呼叫时产生的触发信息；多业务控制器查找所述用户当前签约的所有可用业务，对当前用户签约的所有业务生成业务触发指令列表；多业务控制器将触发指令列表发送给交换设备；以使交换设备根据触发指令列表触发各个业务对应的业务应用服务器完成相应的业务处理过程。

Description

一种业务嵌套的实现方法、多业务控制器和交换设备

技术领域

本发明涉及通信技术领域，尤其涉及一种业务嵌套的实现方法、多业务控制器和交换设备。

背景技术

随着电信的演进，业务的参与方越来越多，业务越来越复杂，此时，在业务控制中众多多业务间的嵌套问题就更加突出。在基于IP的下一代网络中，呼叫和控制相分离，多次触发对交换设备的影响越来越低，不存在原来呼叫控制中信令链路和应用通讯上资源的差异。而标准化的业务触发方式能够解决业务的快速推广。

目前存在一种基于二次触发方式实现两个业务之间的嵌套的方法。该方法实现方式为：首先触发到一个业务系统，该系统的处理逻辑判断如果用户不使用本系统的业务时，携带特殊的号码前缀，交换机进行二次触发到第二业务系统。例如，预付费(PPS)业务使用系统A，VPN业务使用系统B，呼叫首先触发到PPS业务的系统A上，如果PPS业务中判断，用户的预付费账户没有足够的余额，这个时候下发特殊的前缀，触发到VPN业务系统B上。VPN系统B判断，用户可以基于集团代付时，则可以继续接续，否则释放呼叫。该触发机制导致只能最多进行二次触发，无法适用多于两个业务的触发要求，极大的限制了其应用范围。

发明内容

有鉴于此，本发明的目的在于提供一种业务嵌套方法、多业务控制器和交换设备，可以实现多业务的嵌套。

为实现上述目的，本发明实施例提供多业务嵌套方法，包括：

多业务控制器接收到用户发起呼叫时产生的触发信息；

多业务控制器查找所述用户当前签约的所有可用业务，对当前用户签约的所有业务生成业务触发指令列表；

多业务控制器将触发指令列表发送给交换设备；以使交换设备根据触发指令列表触发各个业务对应的业务应用服务器完成相应的业务处理过程。

另一方面，本发明实施例还提供一种多业务嵌套方法，包括：

交换设备接收多业务控制器发送的触发指令列表，所述触发指令列表是由所述多业务控制器查找到的发起呼叫的用户当前签约的所有可用业务生成的；

交换设备根据触发列表触发各个业务对应的业务应用服务器完成相应的业务处理过程。

再一方面，本发明实施例还提供一种多业务控制器，包括：

接收单元，用于接收用户发起呼叫时产生的触发信息；

查找单元，用于查找所述用户当前签约的所有可用业务；

生成单元，用于对当前用户签约的所有业务生成业务触发指令列表；

发送单元，用于将触发指令列表发送给交换设备；以使交换设备根据触发指令列表触发各个业务对应的业务应用服务器完成相应的业务处理过程。

再一方面，本发明实施例还提供一种交换设备，包括：

接收单元，用于接收多业务控制器发送的业务触发指令列表，所述触发指令列表是由所述多业务控制器查找到的发起呼叫的用户当前签约的所有可用业务生成的；

触发单元，用于根据触发指令列表触发各个业务对应的业务应用服务器完成相应的业务处理过程。

在本发明实施例中，采用列表触发的方式，对业务触发的个数没有限制，可以实现多业务的触发，相对于现有技术应用范围更广。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例中的组网方案示意图；

图2a是本发明一实施例提供的一种多业务嵌套实现方法的示意图；

图2b是本发明另一实施例提供的一种多业务嵌套实现方法的示意图；

图3是本发明一实施例提供的一种多业务嵌套的实现方法的示意图；

图4是本发明另一实施例提供的一种多业务嵌套的实现方法的示意图；

图5是本发明另一实施例提供的一种多业务控制器的示意图；

图6是本发明另一实施例提供的一种交换设备的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

当需要支持多业务嵌套触发时，需要提供多业务管理模块。系统提供的各种业务如果需要独立触发，则需要在该多业务控制器登记。

图1示出了本发明实施例中的组网方案示意图。多业务控制器101负责管理完成为每种业务分配一个触发指令，可以是每种业务分配一个前缀，并负责管理多业务的触发顺序，当各个业务分别触发并处理完成后，负责最终的呼叫接续。交换设备102需要支持多次触发能力，可以是按照前缀的业务触发方式。各个应用服务器(包括应用服务器1至应用服务器n)用于在收到业务触发请求后，内部判断相应的处理逻辑，完成相应的处理逻辑，如果需要释放呼叫，则直接释放。

如图2a所示，本发明实施例提供一种多业务嵌套方法，包括：

步骤S201：多业务控制器接收到用户发起呼叫时产生的触发信息；

步骤S202：多业务控制器查找所述用户当前签约的所有可用业务，对当前用户签约的所有业务生成业务触发指令列表；

步骤S203：多业务控制器将触发指令列表发送给交换设备；以使交换设备根据触发指令列表触发各个业务的应用服务器。

本发明另一实施例还提供一种多业务嵌套方法，如图2b所示，该方法包括：

步骤S2011：交换设备接收多业务控制器发送的触发指令列表，所述触发指令列表是由所述多业务控制器查找到的发起呼叫的用户当前签约的所有可用业务生成的；

步骤S2021：交换设备根据触发列表触发各个业务对应的业务应用服务器完成相应的业务处理过程。

其中，对于各个应用服务器可以有多种业务控制模式，以下以两种具体的控制模式详细说明本发明的具体实现。

在本实施例中，业务应用服务器的参与过程是事件式的，业务应用服务器并不参与呼叫过程的控制。业务应用服务器在收到交换设备触发的业务请求后，进行内部的业务处理，根据处理结果判断是否允许呼叫的进行。如果不允许呼叫的进行，则下发呼叫的指示，如果允许呼叫，则下发接续指示，下发接续指示后，可以释放呼叫控制。

具体地，请参见图3，图3示出了本实施例中实现多业务嵌套的方法，包括：

步骤S301：交换设备301接收到用户的呼叫请求；

交换设备可以是MSC或者SSP。

步骤S302-S304：交换设备301向多业务控制器302发送IDP(启动DP)消息，多业务控制器302向交换设备301返回RRBE(Request Report BCSMEvent，请求报告BCSM事件)消息和AC(Apply charging，申请计费)消息。

以上步骤是呼叫触发到多业务控制器302的过程。

步骤S305：多业务控制器302查找发起呼叫的用户当前签约的所有可用业务，并对用户当前签约的所有业务生成业务触发指令列表。

多业务控制器为每个业务分配一个业务触发指令，触发指令方式可以是为每个业务分配一个业务前缀。在实际中前缀触发是交换设备301的一个基本能力。比如拨打800-xxxx-yyyy。交换设备301能够根据800前缀知道这个是一种特殊业务，然后触发到800业务上。相应的生成业务触发指令列表可以是将所有业务前缀顺序拼接。这样，多业务控制器302可以根据拼接后的一串前缀依次触发该前缀对应的业务应用服务器。

步骤S306：多业务控制器302向交换设备301发送业务触发指令列表和被叫号码，可以通过CONNECT消息发送。

步骤S307：交换设备301根据接收到业务触发指令列表，首先触发第一业务应用服务器303，该触发消息可以是IDP消息。

步骤S308：第一业务应用服务器303进行内部的业务处理，完成业务处理过程。

步骤S309：第一业务应用服务器303释放呼叫控制，并向交换设备301返回释放呼叫控制的通知消息，以通知交换设备301第一业务应用服务器303已经释放呼叫控制。在CAP信令中，上述释放呼叫控制的通知消息可以是通过TC_END消息下发接续CONTINUE信令。

步骤S310：交换设备301触发第二业务应用服务器304，该触发消息可以是IDP消息；

步骤S311：第二业务应用服务器304进行内部的业务处理，完成业务处理过程。

步骤S312：第二业务应用服务器304释放呼叫控制过程，并向交换设备301返回释放呼叫控制的通知消息，在CAP信令中，上述释放呼叫控制的通知消息可以是通过TC_END消息下发接续CONTINUE信令。

步骤S313：交换设备301触发第三业务应用服务器305，该触发消息可以是IDP消息。

步骤S314：第三业务应用服务器305进行内部业务处理过程。

步骤S315：第三业务应用服务器305释放呼叫控制过程，并向交换设备301返回释放呼叫控制的通知消息，以通知交换设备301第三业务应用服务器305已经释放呼叫控制。在CAP信令中，释放呼叫控制的通知消息可以是通过TC_END消息下发接续CONTINUE信令。

步骤S316：当最后一个业务应用服务器完成业务处理过程后，通话过程开始。

步骤S317-S318：交换设备301配合多业务控制器302实现呼叫过程的监控，完成后续的呼叫接续处理。具体地，可以包括：交换设备301向多业务控制器302发送ACR(Apply Charging Report，申请计费报告)消息，多业务控制器302向交换设备301返回AC消息。

步骤S319：在呼叫监控过程中，当出现用户挂机时，交换设备301把释放呼叫的信息上报给多业务控制器302，以使多业务控制器301结束呼叫控制。

需要说明的是，本实施例中业务应用服务器实现释放呼叫控制的过程是基于现有的控制协议进行的，例如基于CAP协议，这里不再赘述。

在本实施例中，每个业务应用服务器在被触发并完成各自的业务逻辑后，释放呼叫控制。由于采用列表的触发方式，所以对触发的业务应用服务器的个数没有限制。

另一实施例，在本实施例中，业务应用服务器是参与过程式的，即参与呼叫过程的控制，业务应用服务器在收到交换设备触发的业务请求后，监控用户的挂机时间，同时设定呼叫监控模式。交换设备在触发各个业务应用服务器的过程中，只有业务应用服务器返回接续指示时，才会继续下一个业务应用服务器的触发或呼叫的接续操作，如果某个应用服务器返回释放呼叫指示，则需要释放整个呼叫，并上报给各个参与呼叫监控的业务应用服务器和多业务控制器，待各个参与呼叫监控的业务应用服务器和多业务控制器完成各自内部处理过程后，结束呼叫控制关系。

具体的，请参见图4，图4示出了本实施例中实现多业务嵌套的方法，其中，第二业务应用服务器404参与呼叫过程的控制。并且特别地，本实施例中以下发AC消息进行呼叫的分段监控方式对呼叫过程进行监控。该方法包括：

步骤S401：交换设备401接收到用户的呼叫请求；

交换设备可以是MSC或者SSP。

步骤S402-S404：交换设备401向多业务控制器402发送IDP(启动DP)消息，多业务控制器402向交换设备401返回RRBE(Request Report BCSMEvent，请求报告BCSM事件)消息和AC(Apply charging，申请计费)消息。

以上步骤是呼叫触发到多业务控制器402的过程。

步骤S405：多业务控制器402查找发起呼叫的用户当前签约的所有可用业务，并对用户当前签约的所有业务生成业务触发指令列表。

步骤S406：多业务控制器402向交换设备401发送业务触发指令列表和被叫号码，可以通过CONNECT消息发送。

步骤S407：交换设备401根据接收到的业务触发指令列表，首先触发第一业务应用服务器403，该触发消息可以是IDP消息；

步骤S408：第一业务应用服务器403进行内部的业务处理，完成业务处理过程。

步骤S409：第一业务应用服务器403释放呼叫控制过程，并向交换设备401返回释放呼叫控制的通知消息，以通知交换设备401第一业务应用服务器401已经释放呼叫控制。在CAP信令中，释放呼叫控制一般是通过TC_END消息下发接续CONTINUE信令。

步骤S410：交换设备401触发第二业务应用服务器404，第二业务应用服务器404完成业务处理过程，并设定业务监控模式，对业务监控模式的设定可以具体实现为：第二业务应用服务器404向交换设备401发送RRBE消息和AC消息，以实现呼叫的分段监控。在第二业务应用服务器404完成自身的内部业务逻辑处理后，并不释放对呼叫过程的控制逻辑，如果采用CAP信令，可以通过下发TC_CONTINUE通知消息至交换设备401中，以使交换设备401得知第二业务应用服务器404不释放呼叫控制的目的，并且还可以触发交换设备401开始第三业务应用服务器405的触发过程。

步骤S411：交换设备401触发第三业务应用服务器405，该触发消息可以是IDP消息。

步骤S412：第三业务应用服务器405进行内部业务处理过程。

步骤S413：第三业务应用服务器405释放呼叫控制过程，并向交换设备401返回释放呼叫控制的通知消息，以使交换设备401得知第三业务应用服务器405释放呼叫控制。在CAP信令中，上述释放呼叫控制的通知消息可以是通过TC_END消息下发接续CONTINUE信令。

步骤S414：通话过程开始。

步骤S415-S416：交换设备401配合参与呼叫控制的第二业务应用服务器404进行呼叫过程的监控，具体地，可以包括：交换设备401向第二业务应用服务器404发送ACR消息，第二业务应用服务器404向交换设备401返回AC消息。

步骤S417-S418：交换设备401配合多业务控制器402实现呼叫过程的监控，完成后续的呼叫接续处理。具体地，可以包括：交换设备401向多业务控制器402发送ACR消息，多业务控制器402向交换设备401返回AC消息。

步骤S419：当用户挂机时，交换设备401向参与呼叫控制的第二业务应用服务器404上报释放呼叫的消息，以使第二业务应用服务器404结束呼叫控制。

步骤S420：交换设备401把释放呼叫的信息上报给多业务控制器302，以使多业务控制器402结束呼叫控制。

在本实施例中，呼叫控制维持和释放的具体实现过程都可以基于现有的控制协议，例如CAP协议，这里不再赘述。

另外，在上述各个实施例中，交换设备在触发各个业务应用服务器的过程中，只有业务应用服务器返回接续指示时，才会继续下一个业务应用服务器的触发或呼叫的接续操作。还可以向应用服务器赋予结束整个呼叫的控制权，即如果某个应用服务器向交换设备返回结束整个呼叫的指示，则需要释放整个呼叫，交换设备在接收到上述结束整个呼叫的指示消息后，结束整个呼叫过程。优选的还上报给各个参与呼叫监控的业务应用服务器，待各个参与呼叫监控的业务应用服务器完成各自内部处理过程后，结束各个参与呼叫监控的业务应用服务器的呼叫控制关系。

本实施例中可以实现多个业务应用服务器的嵌套触发，其中“多”是指两个或两个以上。

需要说明的是，以上两个实施例中各个消息均是以CAP协议为例说明的，而对于采用SIP协议的场景中，交换设备向业务应用服务器发送的触发请求可以采用INVITE消息，替换CAP协议中的IDP消息，而释放呼叫控制的消息可以采用200(OK)消息。

本发明的呼叫控制流程适用于各种移动网络，包括且不限于CDMA网络、GSM网络，呼叫控制协议可以是CAP协议，WIN协议，或SIP协议。

本实施例相应提供一种多业务控制器，如图5所示，该多业务控制器500包括接收单元501、查找单元502、生成单元503和发送单元504。其中接收单元501用于接收用户发起呼叫时产生的触发信息，查找单元502用于查找用户当前签约的所有可用业务，生成单元503用于对当前用户签约的所有业务生成业务触发指令列表；发送单元504用于将触发指令列表发送给交换设备；以使交换设备根据触发指令列表顺序触发各个业务对应的业务应用服务器完成相应的业务处理过程。

本发明另一实施例提供一种交换设备，如图6所示，该交换设备600包括接收单元601和触发单元602。

其中，接收单元601用于接收多业务控制器发送的业务触发指令列表，所述触发指令列表是由所述多业务控制器查找到的发起呼叫的用户当前签约的所有可用业务生成的；触发单元602用于根据触发指令列表触发各个业务对应的业务应用服务器完成相应的业务处理过程。

以上多业务控制器以及交换设备的具体实现可参考方法实施例部分，这里不再赘述。

在本发明实施例中，由于采用列表触发的方式，所以对业务触发的个数没有限制，相对于现有技术应用范围更广。

需要说明的是，在本发明各个实施例中提供的方法适用于各种移动网络，包括但不限于CDMA网络、GSM网络，呼叫过程基于的呼叫控制协议可以是CAP协议、WIN协议或SIP协议。

本领域普通技术人员可以理解，实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一计算机可读存储介质中，例如只读存储器(简称ROM)、随机存取存储器(简称RAM)、磁盘、光盘等。

以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。

Claims (11)

1.一种多业务嵌套方法，其特征在于，包括：

多业务控制器接收到用户发起呼叫时产生的触发信息；

多业务控制器查找所述用户当前签约的所有可用业务，对当前用户签约的所有业务生成业务触发指令列表；

多业务控制器将触发指令列表发送给交换设备；以使交换设备根据触发指令列表触发各个业务对应的业务应用服务器完成相应的业务处理过程。

2.根据权利要求1所述的方法，其特征在于，所述业务触发指令包括多业务控制器为每个业务分配的业务前缀，所述业务触发指令列表由所述业务前缀按触发顺序拼接而成。

3.一种多业务嵌套方法，其特征在于，包括：

交换设备接收多业务控制器发送的触发指令列表，所述触发指令列表是由所述多业务控制器查找到的发起呼叫的用户当前签约的所有可用业务生成的；

交换设备根据触发列表触发各个业务对应的业务应用服务器完成相应的业务处理过程。

4.根据权利要求3所述的方法，其特征在于，所述触发指令包括多业务控制器为每个业务分配的业务前缀。

5.根据权利要求4所述的方法，其特征在于，所述触发指令列表由所述用户当前签约的所有可用业务的业务前缀拼接而成；

所述交换设备根据触发列表触发各个业务对应的业务应用服务器完成相应的业务处理过程包括：

所述交换设备根据触发列表中拼接的业务前缀，依次对各个业务前缀对应的业务应用服务器进行触发。

6.根据权利要求3至5中任意一项所述的方法，其特征在于，所述方法还包括：所述交换设备接收业务应用服务器完成业务处理过程后发送的释放呼叫控制的通知消息。

7.根据权利要求3至5中任意一项所述的方法，其特征在于，所述方法还包括：所述交换设备接收业务应用服务器完成业务处理过程后发送的维持呼叫控制的通知消息。

8.根据权利要求3至5中任意一项所述的方法，其特征在于，所述方法还包括：

交换设备接收到业务应用服务器发送的结束整个呼叫的指示；

交换设备结束整个呼叫。

9.根据权利要求8所述的方法，其特征在于，所述方法还包括：

在业务应用服务器向交互设备发送结束整个呼叫的指示以后，

业务应用服务器还向其他参与呼叫控制的业务应用服务器上报结束整个呼叫的通知消息，以使所述其他参与呼叫控制的业务应用服务器在完成自身的处理逻辑后，结束呼叫控制。

10.一种多业务控制器，其特征在于，包括：

接收单元，用于接收用户发起呼叫时产生的触发信息；

查找单元，用于查找所述用户当前签约的所有可用业务；

生成单元，用于对当前用户签约的所有业务生成业务触发指令列表；

发送单元，用于将触发指令列表发送给交换设备；以使交换设备根据触发指令列表触发各个业务对应的业务应用服务器完成相应的业务处理过程。

11.一种交换设备，其特征在于，包括：

接收单元，用于接收多业务控制器发送的业务触发指令列表，所述触发指令列表是由所述多业务控制器查找到的发起呼叫的用户当前签约的所有可用业务生成的；

触发单元，用于根据触发指令列表触发各个业务对应的业务应用服务器完成相应的业务处理过程。

Images