CN102231889A

CN102231889A - 一种业务逻辑处理方法、装置及通信系统

Info

Publication number: CN102231889A
Application number: CN2011102002987A
Authority: CN
Inventors: 陈仁华
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2011-07-18
Filing date: 2011-07-18
Publication date: 2011-11-02
Anticipated expiration: 2031-07-18
Also published as: CN102231889B

Abstract

本发明涉及通信技术领域，公开了一种业务逻辑处理方法、装置及通信系统，其中，业务逻辑处理方法包括：接收内部切换请求，所述内部切换请求由交互逻辑在确定呼叫仅剩下第二业务逻辑时发送，所述内部切换请求包括与第二业务逻辑对应的第二对话号，所述第二对话号与第二有限状态机对应；根据所述第二对话号确定所述第二有限状态机，将所述第二有限状态机修改为与第三对话号对应，将对对话表中与所述第三对话号对应的目的地址进行更新，以使所述第二有限状态机能够根据更新后的目的地址对所述第二业务逻辑的消息进行转发，所述第三对话号与发起所述呼叫的网元对应。使用本发明，可以减少呼叫时延。

Description

一种业务逻辑处理方法、装置及通信系统

技术领域

本发明涉及通信技术领域，具体涉及一种业务逻辑处理方法、装置及通信系统。

背景技术

业务冲突是电信网络中同时为用户提供多个业务所必然导致的结果，为了应对业务冲突的问题，3GPP引入了一个专门负责协调业务运行的功能实体--业务能力交互管理(SCIM：Service Capability Interaction Manager)功能实体，SCIM也称为Service Broker。Service Broker逻辑上位于发起呼叫的网络和实现业务逻辑的网元之间，它的作用是为多个业务的执行提供一个可管理、可控制的方式。为此，Service Broker需要识别用户将触发的业务，知道各种业务执行的顺序，并且当业务之间有潜在冲突时，能够设法阻止冲突的发生。

在典型的Service Broker场景中，一次呼叫会触发Service Broker交互逻辑(Orchestration Application)统一协调两个业务逻辑(Service Logic)进行交互，假设这两个业务逻辑为Service Logic 1和Service Logic 2，当呼叫从网络(假设该网络为核心网)触发上来时，在Service Broker内部，会创建以下有限状态机：

全球移动通信系统业务控制功能有限状态机(gsmSCF FSM：GlobalSystem for Mobile Communications Service Control Function Finite StateMachine)：与Orchestration Application对应，为交互逻辑的呼叫控制有限状态机；

全球移动通信系统业务交换功能有限状态机1(gsmSSF FSM1：GlobalSystem for Mobile Communications Service Switch Function Finite State Machine1)：代理与Service Logic 1对应的核心网，模拟SSF与Service Logic 1交互；

gsmSCF FSM1：Service Logic 1的呼叫控制有限状态机；

gsmSSF FSM2：代理与Service Logic 2对应的核心网，模拟SSF与ServiceLogic 2交互；

gsmSCF FSM2：Service Logic 2的呼叫控制有限状态机。

现有的一种Service Broker进行业务逻辑处理的方法包括：移动交换中心(MSC：Mobile Switching Center)通过启动检出点(IDP：Initial Detection Point)消息触发一个新的呼叫到SCIM，IDP消息包括MSC为该呼叫分配的第三对话号；SCIM触发gsmSCF FSM，gsmSCF FSM与第三对话号对应，再通过gsmSCF FSM触发交互逻辑；交互逻辑在对话表中保存第三对话号与目的地址的对应关系，具体为第三对话号与MSC的地址之间的对应关系，以及第三对话号与交互逻辑的地址之间的对应关系，使交互逻辑可以通过gsmSCF FSM与MSC进行交互，具体地，交互逻辑接收到消息后，根据该消息携带的第三对话号确定对应的gsmSCF FSM，因此将该消息转发至gsmSCF FSM，gsmSCFFSM根据该消息的第三对话号，从对话表中查找与该对话号对应的MSC的地址，则将该消息向MSC转发。其中对话号(Dialogue ID)主要用于标识两个实体或多个实体之间交互的消息，例如第三对话号就可以用于标识MSC、gsmSCF FSM和交互逻辑之间交互的消息，即MSC与gsmSCF FSM之间交互的消息、gsmSCF FSM和交互逻辑之间交互的消息都能够用第三对话号进行标识。

交互逻辑还可以触发Service Logic 1，从而建立与Service Logic 1对应的gsmSSF FSM 1和gsmSCF FSM 1，交互逻辑可以通过gsmSSF FSM 1、gsmSCFFSM 1与Service Logic 1进行交互；交互逻辑还为Service Logic 1分配第一对话号，第一对话号用于标识交互逻辑、gsmSSF FSM 1、gsmSCF FSM 1与Service Logic 1之间交互的消息，即在业务逻辑1的执行过程中交互逻辑与gsmSSF FSM 1之间交互的消息、gsmSSF FSM 1与gsmSCF FSM 1之间交互的消息、gsmSCF FSM 1与Service Logic 1之间交互的消息都可以用第一对话号进行标识；并且在对话表中保存第一对话号与目的地址的对应关系，具体为第一对话号与交互逻辑的地址，以及第一对话号与Service Logic 1的地址之间的对应关系。具体地，gsmSCF FSM 1接收到来自Service Logic 1的消息后，根据第一对话号确定对应的gsmSSF FSM 1，因此向gsmSSF FSM 1转发该消息，gsmSSF FSM 1根据第一对话号从对话表中查找出目的地址为交互逻辑的地址，因此通过gsmSSF FSM 1将该消息发送至交互逻辑。

交互逻辑还可以触发Service Logic 2，从而建立与Service Logic 2对应的gsmSSF FSM 2和gsmSCF FSM 2，交互逻辑可以通过gsmSSF FSM 2、gsmSCFFSM 2与Service Logic 2进行交互；交互逻辑还为Service Logic 2分配第一对话号，第二对话号用于标识交互逻辑、gsmSSF FSM 2、gsmSCF FSM 2与Service Logic 2之间交互的消息，即在业务逻辑2的执行过程中交互逻辑与gsmSSF FSM 2之间交互的消息、gsmSSF FSM 2与gsmSCF FSM 2之间交互的消息、gsmSCF FSM 2与Service Logic 2之间交互的消息都可以用第二对话号进行标识；并且在对话表中保存第二对话号与目的地址的对应关系，具体为第二对话号与交互逻辑的地址，以及第二对话号与Service Logic 2的地址之间的对应关系。具体地，gsmSCF FSM 2接收到来自Service Logic 2的消息后，根据第二对话号确定对应的gsmSSF FSM 2，因此向gsmSSF FSM 2转发该消息，gsmSSF FSM 2根据第二对话号从对话表中查找出目的地址为交互逻辑的地址，因此通过gsmSSF FSM 2将该消息发送至交互逻辑。

使用上述Service Broker进行业务逻辑处理的方法虽然能够协调多个业务进行交互，但是当业务逻辑执行到一定阶段后，被Service Broker触发的业务逻辑会只剩下一个继续执行，例如，交互逻辑协调Service Logic 1和ServiceLogic 2两个业务交互，当执行一段时间后，Service Logic 1结束，只剩下ServiceLogic 2继续执行，此时Service Logic 2与MSC之间的消息交互还需要通过交互逻辑，并且此时交互逻辑也只是起到了信令中转的作用，导致消息需要在Service Broker内部的各个有限状态机以及交互逻辑之间转发，增加了呼叫时延。

发明内容

本发明实施例提供了一种业务逻辑处理方法、装置及通信系统，可以减少呼叫时延。

本发明实施例提供了一种业务逻辑处理方法，包括：

接收内部切换请求，所述内部切换请求由交互逻辑在确定呼叫仅剩下第二业务逻辑时发送，所述内部切换请求包括与第二业务逻辑对应的第二对话号，所述第二对话号与第二有限状态机对应；

根据所述第二对话号确定所述第二有限状态机，将所述第二有限状态机修改为与第三对话号对应，将对对话表中与所述第三对话号对应的目的地址进行更新，以使所述第二有限状态机能够根据更新后的目的地址对所述第二业务逻辑的消息进行转发，所述第三对话号与发起所述呼叫的网元对应。

本发明实施例还提供了一种业务逻辑处理装置，包括：

接收单元，用于接收内部切换请求，所述内部切换请求由交互逻辑在确定呼叫仅剩下第二业务逻辑时发送，所述内部切换请求包括与第二业务逻辑对应的第二对话号，所述第二对话号与第二有限状态机对应；

保存单元，用于保存对话表；

更新单元，用于在所述接收单元接收了所述内部切换请求后，根据所述第二对话号确定所述第二有限状态机，将所述第二有限状态机修改为与第三对话号对应，对所述保存单元保存的对话表中与所述第三对话号对应的目的地址进行更新，以使所述第二有限状态机能够根据更新后的目的地址对所述第二业务逻辑的消息进行转发，所述第三对话号与发起所述呼叫的网元对应。

本发明实施例还提供了一种通信系统，包括本发明实施例提供的业务逻辑处理装置。

从本发明实施例提供的以上技术方案可以看出，本发明实施例中ServiceBroker在交互逻辑在确定呼叫仅剩下第二业务逻辑时，可以接收到交互逻辑发送的内部切换请求，从而可以将第二有限状态机修改为与第三对话号对应，以及将对对话表中与第三对话号对应的目的地址进行更新，从而使第二有限状态机能够根据更新后的目的地址对第二业务逻辑的消息进行转发，具体可以直接将来自第二业务逻辑的消息向网元转发，以及将来自网元的消息向第二业务逻辑转发，减少了第二业务逻辑与网元之间消息需要经过的有限状态机的数量，从而减少呼叫时延。

附图说明

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

图1为本发明一个实施例提供的业务逻辑处理方法的流程图；

图2为本发明另一个实施例提供的业务逻辑处理方法的信令流程图；

图3为本发明另一个实施例提供的业务逻辑处理方法的信令流程图；

图4为本发明一个实施例提供的业务逻辑处理装置的结构图；

图5为本发明另一个实施例提供的业务逻辑处理装置的结构图。

具体实施方式

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

先介绍本发明实施例提供的业务逻辑处理方法，本发明实施例提供的业务逻辑处理方法描述的是Service Broker，具体是Service Broker中与交互逻辑对应的gsmSCF FSM的处理流程；本发明实施例提供的业务逻辑处理方法的应用场景如下：一个网络的网元向Service Broker发起呼叫，该呼叫会在ServiceBroker触发与该呼叫对应的交互逻辑，该交互逻辑会在Service Broker上触发了至少两个业务逻辑，包括第一业务逻辑和第二业务逻辑，其中第一业务逻辑先于第二业务逻辑结束，第一业务逻辑的数量可以为1个或2个以上。

图1描述了本发明一个实施例提供的业务逻辑处理方法的流程，包括：

101、接收内部切换请求，该内部切换请求由交互逻辑在确定呼叫仅剩下第二业务逻辑时发送，该内部切换请求包括与第二业务逻辑对应的第二对话号，第二对话号与第二有限状态机对应。

具体是Service Broker中与交互逻辑对应的gsmSCF FSM接收来自交互逻辑的该内部切换请求，由于交互逻辑也是Service Broker中的一个装置，因此该内部切换请求为内部消息。其中，本发明实施例中两者对应是指能够根据两者中的任意一方确定另一方，例如第二对话号与第二有限状态机对应是指根据第二对话号能够确定第二有限状态机，以及根据第二有限状态机能够确定第二对话号。其中，Service Broker中的每一个有限状态机都有唯一的标识，因此Service Broker中可以保存有限状态机的标识与对话号的关系，从而保存有限状态机与对话号的对应关系。其中，本发明实施例并不限定有限状态机与对话号的对应关系在Service Broker中的保存位置，只要保存的该对应关系能够被Service Broker中的装置所读取就不会影响本发明实施例的实现。

由于一个呼叫会触发哪些业务逻辑，以及这些业务逻辑的执行顺序，以及各个业务逻辑的结束时间都是预先可知的，因此可以保存配置文件，该配置文件记录各个业务逻辑的执行顺序，以及在什么情况下触发哪个业务逻辑；在本发明实施例中，还可以记录什么情况下能够确定呼叫仅剩下第二业务逻辑，例如在最后一个第一业务逻辑结束时可以确定仅剩下第二业务逻辑，在第二业务逻辑开始时可以确定仅剩下第二业务逻辑等。因此，交互逻辑在触发了第二业务逻辑或在第一业务逻辑结束时，可以根据保存的配置文件确定呼叫仅剩下第二业务逻辑。

102、根据第二对话号确定第二有限状态机，将第二有限状态机修改为与第三对话号对应，将对对话表中与第三对话号对应的目的地址进行更新，以使第二有限状态机能够根据更新后的目的地址对第二业务逻辑的消息进行转发，该第三对话号与发起呼叫的网元对应。

由于Service Broker保存了对话号与有限状态机的对应关系，因此可以根据第二对话号确定对应的第二有限状态机；其中，将第二有限状态机修改为与第三对话号对应具体可以为：将第二有限状态机的标识修改为与第三对话号对应。发起呼叫的网元根据该网元所处网络的不同会有不同，例如可以是核心网的MSC等。

其中，在第二业务逻辑为Service Broker的内部业务时，与第二对话号相关的有限状态机包括gsmSCF FSM 2和gsmSSF FSM 2，此时，上述的第二有限状态机可以为gsmSCF FSM 2或gsmSSF FSM 2；具体地，在第二业务逻辑与交互逻辑位于同一呼叫控制点，即第二业务逻辑与交互逻辑对应同一个应用服务器时，第二业务逻辑称为Service Broker的内部业务。在第二业务逻辑为Service Broker的外部业务时，Service Broker中与第二对话号相关的有限状态机包括gsmSSF FSM 2，此时，上述的第二有限状态机可以为gsmSCF FSM2；具体地，在第二业务逻辑与交互逻辑位于不同的呼叫控制点时，第二业务逻辑称为Service Broker的外部业务。

对话表保存在Service Broker中，以对话号作为索引，每一个对话号对应一个表项，每一个表项都保存有与对话号对应的目的地址，包括发起呼叫的网元的地址、和/或有限状态机的标识、和/或交互逻辑的地址、和/或业务逻辑的地址等，其中，本发明实施例并不限定对话表保存在Service Broker中的具体位置，只要该对话表能够被Service Broker中的装置所读取都不会影响本发明实施例的实现。例如，在本发明的一个实施例中，在对话表中保存的与第三对话号对应的目的地址可以包括：发起呼叫的网元的地址和交互逻辑的地址；在本发明的另一个实施例中，对话号与有限状态机的对应关系也可以保存在对话表中，此时在对话表中保存的与第三对话号对应的目的地址可以包括：发起呼叫的网元的地址，交互逻辑的地址和gsmSCF FSM的标识。对话表中保存的与第二对话号对应的目的地址可以包括交互逻辑的地址和第二业务逻辑的地址，或者还可以包括gsmSCF FSM2的标识和gsmSSF FSM2的标识。此时，对对话表中与第三对话号对应的目的地址进行更新包括：将第三对话号对应的交互逻辑的地址更新为第二业务逻辑的地址，即更新后的第三对话号对应的目的地址包括发起呼叫的网元的地址和第二业务逻辑的地址，使得第二有限状态机可以直接将来自第二业务逻辑的消息向网元转发，以及将来自网元的消息向第二业务逻辑转发。

其中，在一次呼叫中的所有对话号对应的表项都存储在同一个对话表中时，每触发一个业务逻辑，都会为该触发的业务逻辑分配一个对话号，并且在对话表中增加该对话号的表项；在一个业务逻辑执行完时，则可以将对话表中该执行完的业务逻辑对应的对话号的表项删除，当然，也可以在呼叫完成后，直接将该呼叫对应的对话表删除。

本发明一个实施例提供的一次呼叫中更新前的对话表如表1所示。

表1

其中，Service Broker中的装置都知道与该装置连接的另外两个装置，例如，gsmSCF FSM 1知道与之连接的两个装置分别是交互逻辑和gsmSSF FSM1，因此gsmSCF FSM 1在接收到一个消息后，可以根据消息类型、和/或消息来源等确定该消息是来自交互逻辑还是gsmSSF FSM 1，然后再根据该消息的第一对话号从对话表中查找到目的地址，该目的地址在该消息来自交互逻辑时是gsmSSF FSM 1，在该消息来自gsmSSF FSM 1时是交互逻辑。

本发明该实施例提供的一次呼叫中更新后的对话表如表2所示。

表2

从上可知，本实施例中Service Broker在交互逻辑在确定呼叫仅剩下第二业务逻辑时，可以接收到交互逻辑发送的内部切换请求，从而可以将第二有限状态机修改为与第三对话号对应，以及将对对话表中与第三对话号对应的目的地址进行更新，从而使第二有限状态机能够根据更新后的目的地址对第二业务逻辑的消息进行转发，具体可以直接将来自第二业务逻辑的消息向网元转发，以及将来自网元的消息向第二业务逻辑转发，减少了第二业务逻辑与网元之间消息需要经过的有限状态机的数量，从而减少呼叫时延。

在本发明的另一个实施例中，Service Broker在对对话表中与第三对话号对应的目的地址进行更新后，可以进一步删除对话表中与第二对话号对应的表项，以及删除与第一对话号对应的表项，该第一对话号与呼叫已经结束的第一业务逻辑对应；由于呼叫已经只剩下第二业务逻辑还在执行，并且第二业务逻辑对应的对话号也已经更新为第三对话号，因此与第二对话号和第一对话号对应的表项都不会再被使用，因此可以删除与第一对话号和第二对话号对应的表项，可以减少对话表需要存储的表项，从而减少对话表需要使用的存储空间，并且减少对话表中存储的表项数量，还可以提高检索速度。

在本发明的另一个实施例中，Service Broker在接收到内部切换请求后，还可以结束除第二有限状态机外的所有与呼叫对应的有限状态机的运行，以及结束与呼叫对应的交互逻辑的运行。其中，每一个呼叫都会在Service Broker中触发一个交互逻辑；而且交互逻辑每触发一个内部业务逻辑，Service Broker都会创建gsmSSF FSM和gsmSCF FSM这两个有限状态机；交互逻辑每创建一个外部业务逻辑，Service Broker都会创建gsmSSF FSM这一个有限状态机。由于在对对话表中与第三对话号对应的目的地址进行更新后，除了上述第二有限状态机外的其他与该呼叫对应的有限状态机都不会再被使用，交互逻辑也不会再被使用，因此可以结束这些不需要使用的有限状态机和交互逻辑的运行，从而释放这些有限状态机和交互逻辑占用的资源，提高Service Broker中系统资源的利用效率。

图2描述了本发明另一个实施例提供的业务逻辑处理方法的信令流程，该实施例中第二业务逻辑是Service Broker的内部业务，发起呼叫的网元为MSC，该实施例包括：

201、MSC向Service Broker发送第三IDP消息触发一个新的呼叫，ServiceBroker创建gsmSCF FSM，Service Broker触发交互逻辑，Service Broker将第三IDP消息发送至gsmSCF FSM；其中，第三IDP消息可以携带MSC分配的第三对话号，gsmSCF FSM与该第三对话号对应，并且MSC也与第三对话号对应。在Service Broker中，每一个有限状态机都有唯一的标识，并且会保存有限状态机的标识与对话号的对应关系，因此在需要向某一个有限状态机转发消息时，可以根据该消息的对话号确定对应的有限状态机的标识，从而根据确定的有限状态机的标识转发该消息。具体地，有限状态机的标识与对话号的对应关系可以保存在对话表中，当然Service Broker也可以在其他的表或采用其他的方式保存有限状态机的标识与对话号的对应关系。

其中第三IDP消息是由MSC在基本呼叫状态模型(BCSM：Basic Call StateModel)中检测到触发检测点请求(TDP-R：Trigger Detection Point-Request)后发送的完成呼叫的指令。

202、gsmSCF FSM向交互逻辑转发第三IDP消息。

进一步，交互逻辑在接收到第三IDP消息后，会在对话表中保存与第三对话号对应的目的地址，具体包括交互逻辑的地址和MSC的地址，因此gsmSCF FSM可以根据第三对话号从对话表中找到交互逻辑的地址，因此gsmSCF FSM可以向交互逻辑转发第三IDP消息。

203、交互逻辑根据保存的配置文件触发第一业务逻辑，Service Broker创建gsmSSF FSM 1和gsmSCF FSM 1，使交互逻辑与第一业务逻辑通过gsmSSF FSM 1和gsmSCF FSM 1进行交互。交互逻辑向gsmSSF FSM 1发送第一IDP消息。第一业务逻辑根据呼叫的不同会有不同，例如第一业务逻辑的功能可以是在接收到第一IDP消息进行呼叫鉴权后，下发Continue消息继续呼叫。

其中，交互逻辑触发第一业务逻辑后，为第一业务逻辑分配第一对话号，并在对话表中增加与第一对话号对应的目的地址，具体包括交互逻辑的地址和第一业务逻辑的地址，或者还可以包括gsmSSF FSM 1的标识和gsmSCFFSM 1的标识。当然，也可以通过其他的记录表或其他的保存方式保存gsmSSFFSM 1的标识和gsmSCF FSM 1的标识与第一对话号的对应关系。

204、gsmSSF FSM 1向gsmSCF FSM 1转发第一IDP消息。

gsmSSF FSM 1可以根据第一对话号查找到gsmSCF FSM 1的标识，从而向gsmSCF FSM 1转发第一IDP消息。

205、gsmSCF FSM 1向第一业务逻辑转发第一IDP消息。

gsmSCF FSM 1可以根据第一对话号从对话表中查找到第一业务逻辑的地址，从而向第一业务逻辑转发第一IDP消息。具体地，gsmSCF FSM 1接收到第一IDP消息后，可以确定第一IDP消息由交互逻辑发出，因此可以确定应该将第一IDP消息向第一业务逻辑转发。

206、第一业务逻辑向gsmSCF FSM 1发送第一继续(Continue)消息。

其中，第一业务逻辑具体是向Service Broker发送第一Continue消息，Service Broker可以根据第一Continue消息的第一对话号确定应该向gsmSCFFSM 1发送，因此Service Broker接收到第一Continue消息后会直接向gsmSCFFSM 1转发，也就相当于第一业务逻辑直接向gsmSCF FSM 1发送。其中，第一Continue消息的第一对话号是由Service Broker接收到第一Continue消息后，根据该第一Continue消息的发送者，即第一业务逻辑确定的；ServiceBroker在确定第一Continue消息的第一对话号后，会将第一对话号加在第一Continue消息中发送给gsmSCF FSM 1，使gsmSCF FSM 1能够直接确定第一Continue消息对应的第一对话号。

207、gsmSCF FSM 1向gsmSSF FSM 1转发第一Continue消息。

gsmSCF FSM 1可以根据第一对话号查找到gsmSSF FSM 1的标识，从而向gsmSSF FSM 1转发第一Continue消息。

208、gsmSSF FSM 1向交互逻辑转发第一Continue消息。交互逻辑接收到第一Continue消息后，确定第一业务逻辑结束。

gsmSSF FSM 1可以根据第一对话号从对话表中查找到交互逻辑的地址，从而向交互逻辑转发Continue消息。

209、交互逻辑根据保存的配置文件触发第二业务逻辑，Service Broker创建gsmSSF FSM 2和gsmSCF FSM 2，使交互逻辑与第二业务逻辑通过gsmSSF FSM 2和gsmSCF FSM 2进行交互。交互逻辑向gsmSSF FSM 1发送第二IDP消息，该第二IDP消息包括交互逻辑分配的第二对话号。

其中，交互逻辑触发第二业务逻辑后，为第二业务逻辑分配第二对话号，并在对话表中增加与第二对话号对应的目的地址，具体包括交互逻辑的地址和第二业务逻辑的地址，或者还可以包括gsmSSF FSM 2的标识和gsmSCFFSM 2的标识。当然，也可以通过其他的记录表或其他的保存方式保存gsmSSFFSM 2的标识和gsmSCF FSM 2的标识与第二对话号的对应关系。

第二业务逻辑根据呼叫的不同会有不同，例如第二业务逻辑的功能可以是在接收到第二IDP消息后，下发RRBE消息监视主被叫的相关事件，以及后续的计费操作等。

210、gsmSSF FSM 2向gsmSCF FSM 2转发第二IDP消息。

gsmSSF FSM 2可以根据第二对话号查找到gsmSCF FSM 2的标识，从而向gsmSCF FSM 2转发第二IDP消息。

211、gsmSCF FSM 2向第二业务逻辑转发第二IDP消息。

gsmSCF FSM 2可以根据第二对话号从对话表中查找到第二业务逻辑的地址，从而向第二业务逻辑转发第二IDP消息。

212、第二业务逻辑通过gsmSCF FSM 2和gsmSSF FSM 2向交互逻辑发送请求报告BCSM事件(RRBE：Request Report BCSM Event)消息。

具体地，第二业务逻辑向gsmSCF FSM 2发送RRBE消息，然后gsmSCFFSM 2向gsmSSF FSM 2转发该RRBE消息，再由gsmSSF FSM 2向交互逻辑转发该RRBE消息。

213、交互逻辑通过gsmSCF FSM向MSC转发RRBE消息。

214、交互逻辑在接收到RRBE消息后，根据配置文件确定此时呼叫仅剩下第二业务逻辑，向Service Broker发送内部消息，该内部消息为内部切换(inter-handover)请求，以使Service Broker进行呼叫过程中的切换(handover)，内部切换消息包括第二对话号；Service Broker接收到内部切换请求后，根据第二对话号确定gsmSCF FSM 2，并将gsmSCF FSM 2修改为与第三对话号对应，以及将第二业务逻辑修改为与第三对话号对应，并且将对话表中第三对话号对应的目的地址进行更新，具体是将交互逻辑的地址修改为第二业务逻辑的地址。

Service Broker可以进一步删除对话表中与第二对话号对应的表项，以及与第一对话号对应的表项。进一步，还可以结束gsmSCF FSM 1、gsmSSF FSM1、gsmSSF FSM 2、gsmSCF FSM和交互逻辑的运行。

其中，可以理解的是，根据配置文件的不同，交互逻辑还可以在其他的时机确定呼叫仅会剩下第二业务逻辑，例如在接收到第一业务逻辑发送的第一Continue消息时，交互逻辑可以确定第一业务逻辑已经结束，从而确定呼叫仅剩下第二业务逻辑；例如交互逻辑在触发第二业务逻辑时，也可以确定呼叫仅剩下第二业务逻辑。

215、第二业务逻辑向gsmSCF FSM 2发送第二Continue消息。

其中，第二业务逻辑具体是向Service Broker发送第二Continue消息，由于gsmSCF FSM 2已经修改为与第三对话号对应，因此Service Broker可以根据该第二Continue消息的第三对话号确定应该向gsmSCF FSM 2发送，因此Service Broker接收到第二Continue消息后会直接向gsmSCF FSM 2转发，也就相当于第二业务逻辑直接向gsmSCF FSM 2发送。其中，第二Continue消息的第三对话号是由Service Broker接收到第二Continue消息后，根据第二Continue消息的发送者第二业务逻辑确定的；Service Broker在确定第二Continue消息的第三对话号后，会将第三对话号加在第二Continue消息中发送给gsmSCF FSM 2，使gsmSCF FSM 2能够直接确定第二Continue消息对应的第三对话号。

216、gsmSCF FSM 2根据第三对话号从对话表中找到MSC的地址，直接将第二Continue消息转发给MSC。

由于对话表中第三对话号对应的目的地址包括MSC的地址，并且第二Continue消息是由第二业务逻辑发出，因此gsmSCF FSM 2可以确定直接将第二Continue消息转发给MSC。

217、MSC向Service Broker发送BCSM事件报告(ERB：Event ReportBCSM)消息，Service Broker根据第三对话号直接向gsmSCF FSM 2转发该ERB消息。

其中，第三对话号可以是MSC已经在BCSM事件报告消息中携带，或者由Service Broker接收到BCSM事件报告消息后，根据BCSM事件报告消息的发送者是MSC直接确定对话号为第三对话号

218、gsmSCF FSM 2根据第三对话号从对话表中找到第二业务逻辑的地址，直接将ERB消息转发给第二业务逻辑。

219、第二业务逻辑通过gsmSCF FSM 2向MSC发送申请计费(AC：ApplyCharging)消息。

220、MSC通过gsmSCF FSM 2向第二业务逻辑发送申请计费报告(ACR：Apply Charging Report)消息。

221、第二业务逻辑通过gsmSCF FSM 2向MSC发送释放呼叫(RC：Release Call)消息。

图3描述了本发明另一个实施例提供的业务逻辑处理方法的信令流程，该实施例中第二业务逻辑是Service Broker的外部业务，发起呼叫的网元为MSC，该实施例包括：

301、MSC向Service Broker发送第三IDP消息触发一个新的呼叫，ServiceBroker创建gsmSCF FSM，Service Broker触发交互逻辑，Service Broker将第三IDP消息发送至gsmSCF FSM；其中，IDP消息携带有MSC分配的第三对话号，gsmSCF FSM与该第三对话号对应，并且MSC也与第三对话号对应。在Service Broker中，每一个有限状态机都有唯一的标识，并且会保存有限状态机的标识与对话号的对应关系，因此在需要向某一个有限状态机转发消息时，可以根据该消息的对话号确定对应的有限状态机的标识，从而根据确定的有限状态机的标识转发该消息。具体地，有限状态机的标识与对话号的对应关系可以保存在对话表中，当然Service Broker也可以在其他的表或采用其他的方式保存有限状态机的标识与对话号的对应关系。

其中第三IDP消息是在基本呼叫状态模型(BCSM：Basic Call State Model)中检测到触发检测点请求(TDP-R：Trigger Detection Point-Request)后发送的完成呼叫的指令。

302、gsmSCF FSM向交互逻辑转发第三IDP消息。

交互逻辑会在对话表中保存与第三对话号对应的目的地址，具体包括交互逻辑的地址和MSC的地址，因此gsmSCF FSM可以根据第三对话号从对话表中找到交互逻辑的地址，因此gsmSCF FSM可以向交互逻辑转发第三IDP消息。

303、交互逻辑根据保存的配置文件触发第一业务逻辑，Service Broker创建gsmSSF FSM 1和gsmSCF FSM 1，使交互逻辑与第一业务逻辑通过gsmSSF FSM 1和gsmSCF FSM 1进行交互。交互逻辑向gsmSSF FSM 1发送第一IDP消息。

304、gsmSSF FSM 1向gsmSCF FSM 1转发第一IDP消息。

305、gsmSCF FSM 1向第一业务逻辑转发第一IDP消息。

gsmSCF FSM 1可以根据第一对话号从对话表中查找到第一业务逻辑的地址，从而向第一业务逻辑转发第一IDP消息。具体地，gsmSCF FSM 1接收到第一IDP消息后，可以确定该IDP消息由MSC发出，因此可以确定应该将该第一IDP消息向交互逻辑转发。

306、第一业务逻辑向gsmSCF FSM 1发送第一Continue消息。

其中，第一业务逻辑具体是向Service Broker发送第一Continue消息，Service Broker可以根据第一Continue消息的第一对话号确定应该向gsmSCFFSM 1发送，因此Service Broker接收到第一Continue消息后会直接向gsmSCFFSM 1转发，也就相当于第一业务逻辑直接向gsmSCF FSM 1发送。其中，Continue消息的第一对话号是由Service Broker接收到Continue消息后，根据第一Continue消息的发送者第一业务逻辑确定的；Service Broker在确定第一Continue消息的第一对话号后，会将第一对话号加在第一Continue消息中发送给gsmSCF FSM 1，使gsmSCF FSM 1能够直接确定第一Continue消息对应的第一对话号。

307、gsmSCF FSM 1向gsmSSF FSM 1转发第一Continue消息。

gsmSCF FSM 1可以根据第一对话号查找到gsmSSF FSM 1的标识，从而向gsmSSF FSM 1转发Continue消息。

308、gsmSSF FSM 1向交互逻辑转发第一Continue消息。交互逻辑接收到第一Continue消息后，可以确定第一业务逻辑结束。

gsmSSF FSM 1可以根据第一对话号从对话表中查找到交互逻辑的地址，从而向交互逻辑转发第一Continue消息。

309、交互逻辑根据保存的配置文件触发第二业务逻辑，Service Broker创建gsmSSF FSM 2，使交互逻辑与第二业务逻辑通过gsmSSF FSM 2进行交互。交互逻辑向gsmSSF FSM 2发送第二IDP消息，该IDP消息包括交互逻辑分配的第二对话号。

其中，由于第二业务逻辑是Service Broker的外部业务，因此ServiceBroker只需要创建gsmSSF FSM 2，而gsmSCF FSM 2则由第二业务逻辑所处的业务系统创建。

其中，交互逻辑触发第二业务逻辑后，为第二业务逻辑分配第二对话号，并在对话表中增加与第二对话号对应的目的地址，具体包括交互逻辑的地址和第二业务逻辑的地址，或者还可以包括gsmSSF FSM 2的标识。当然，也可以通过其他的记录表或其他的保存方式保存gsmSSF FSM 2的标识与第二对话号的对应关系。

310、gsmSSF FSM 2向第二业务逻辑转发第二IDP消息。

gsmSSF FSM 2可以根据第二对话号从对话表中查找到第二业务逻辑的地址，从而向第二业务逻辑转发第二IDP消息。

311、第二业务逻辑通过gsmSSF FSM 2向交互逻辑发送RRBE消息。

312、交互逻辑通过gsmSCF FSM向MSC转发RRBE消息。

313、交互逻辑在接收到RRBE消息后，通过gsmSSF FSM向MSC转发RRBE消息。

314、交互逻辑在接收到RRBE消息后，根据配置文件确定此时呼叫仅剩下第二业务逻辑，向Service Broker发送内部消息，该内部消息为内部切换请求，以使Service Broker进行呼叫过程中的切换，内部切换消息包括第二对话号；Service Broker接收到内部切换请求后，根据第二对话号确定gsmSSF FSM2，并将gsmSSF FSM 2修改为与第三对话号对应，以及将第二业务逻辑修改为与第三对话号对应，并且将对话表中第三对话号对应的目的地址进行更新，具体是将交互逻辑的地址修改为第二业务逻辑的地址。

Service Broker可以进一步删除对话表中与第二对话号对应的表项，以及与第一对话号对应的表项。进一步，还可以结束gsmSCF FSM 1、gsmSSF FSM1、gsmSCF FSM和交互逻辑的运行。

315、第二业务逻辑向gsmSSF FSM 2发送第二Continue消息。

其中，第二业务逻辑具体是向Service Broker发送第二Continue消息，由于gsmSSF FSM 2已经修改为与第三对话号对应，因此Service Broker可以根据第二Continue消息的第三对话号确定应该向gsmSSF FSM 2发送，因此Service Broker接收到第二Continue消息后会直接向gsmSSF FSM 2转发，也就相当于第二业务逻辑直接向gsmSSF FSM 2发送。其中，第二Continue消息的第三对话号是由Service Broker接收到第二Continue消息后，根据第二Continue消息的发送者，即第二业务逻辑确定的；Service Broker在确定第二Continue消息的第三对话号后，会将第三对话号加在第二Continue消息中发送给gsmSSF FSM 2，使gsmSSF FSM 2能够直接确定第二Continue消息对应的第三对话号。

316、gsmSSF FSM 2根据第三对话号从对话表中找到MSC的地址，直接将第二Continue消息转发给MSC。

由于对话表中第三对话号对应的目的地址包括MSC的地址，并且第二Continue消息是由第二业务逻辑发出，因此gsmSSF FSM 2可以确定直接将第二Continue消息转发给MSC。

317、MSC向Service Broker发送ERB消息，Service Broker根据第三对话号直接向gsmSSF FSM 2转发该ERB消息。

318、gsmSSF FSM 2根据第三对话号从对话表中找到第二业务逻辑的地址，直接将ERB消息转发给第二业务逻辑。

319、第二业务逻辑通过gsmSSF FSM 2向MSC发送AC消息。

320、MSC通过gsmSSF FSM 2向第二业务逻辑发送ACR消息。

321、第二业务逻辑通过gsmSSF FSM 2向MSC发送RC消息。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本发明并不受所描述的动作顺序的限制，因为依据本发明，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于优选实施例，所涉及的动作和模块并不一定是本发明所必须的。

如下再介绍本发明实施例提供的业务逻辑处理装置，本发明实施例中业务逻辑处理装置可以作为Service Broker的一个内部模块使用，也可以直接作为Service Broker使用，其中，在业务逻辑处理装置作为Service Broker的一个内部模块使用时，具体可以作为与交互逻辑对应的gsmSCF FSM使用，因此本发明实施例提供的业务逻辑处理装置可以实现上述方法实施例中gsmSCF FSM的所有功能。图4描述了本发明一个实施例提供的业务逻辑处理装置的结构，包括：

接收单元401，用于接收内部切换请求，该内部切换请求由交互逻辑在确定呼叫仅剩下第二业务逻辑时发送，该内部切换请求包括与第二业务逻辑对应的第二对话号，第二对话号与第二有限状态机对应。

保存单元402，用于保存对话表。

更新单元403，用于在接收单元401接收了内部切换请求后，根据第二对话号确定第二有限状态机，将第二有限状态机修改为与第三对话号对应，对保存单元402保存的对话表中与第三对话号对应的目的地址进行更新，以使第二有限状态机能够根据更新后的目的地址对第二业务逻辑的消息进行转发；其中，第三对话号与发起呼叫的网元对应。

图5描述了本发明另一个实施例提供的业务逻辑处理装置的结构，该实施例提供的业务逻辑处理装置与图4描述的业务逻辑处理装置相比，多了结束单元504，用于在接收单元401接收了内部切换请求后，结束除第二有限状态机外的所有与呼叫对应的有限状态机的运行，以及结束交互逻辑的运行。从而释放这些有限状态机和交互逻辑占用的资源，提高Service Broker中系统资源的利用效率。

在本发明实施例提供的业务逻辑处理装置中，第三对话号对应的目的地址包括交互逻辑的地址和发起呼叫的网元的地址；此时，更新单元403，具体可以用于将与第三对话号对应的交互逻辑的地址更新为第二业务逻辑的地址。

在本发明实施例提供的业务逻辑处理装置中，更新单元403，还可以用于删除保存单元402保存的对话表中与第二对话号对应的表项，以及删除与第一对话号对应的表项，第一对话号与呼叫已经结束的第一业务逻辑对应。可以减少对话表需要存储的表项，从而减少对话表需要使用的存储空间，并且减少对话表中存储的表项数量，还可以提高检索速度。

本发明实施例还提供了通信系统，该通信系统包括本发明实施例提供的业务逻辑处理装置。

上述装置和系统内的各模块之间的信息交互、执行过程等内容，由于与本发明方法实施例基于同一构思，具体内容可参见本发明方法实施例中的叙述，此处不再赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述的存储介质可为磁碟、光盘、只读存储记忆体(ROM：Read-Only Memory)或随机存储记忆体(RAM：Random Access Memory)等。

本文中应用了具体个例对本发明的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本发明的方法及其思想；同时，对于本领域的一般技术人员，依据本发明的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。

Claims

1.一种业务逻辑处理方法，其特征在于，包括：

2.如权利要求1所述的业务逻辑处理方法，其特征在于，所述第三对话号对应的目的地址包括交互逻辑的地址和所述网元的地址；

所述对对话表中与所述第三对话号对应的目的地址进行更新包括：将与所述第三对话号对应的交互逻辑的地址更新为第二业务逻辑的地址；

所述第二有限状态机根据更新后的目的地址对所述第二业务逻辑的消息进行转发包括：将来自所述第二业务逻辑的消息根据所述网元的地址向所述网元转发，以及将来自所述网元的消息根据所述第二业务逻辑的地址向所述第二业务逻辑转发。

3.如权利要求1所述的业务逻辑处理方法，其特征在于，所述交互逻辑在触发所述第二业务逻辑、或在所述第一业务逻辑结束时，根据保存的配置文件确定所述呼叫仅剩下所述第二业务逻辑。

4.如权利要求1至3任一所述的业务逻辑处理方法，其特征在于，对对话表中与所述第三对话号对应的目的地址进行更新后进一步包括：

删除所述对话表中与所述第二对话号对应的表项，以及删除与第一对话号对应的表项，所述第一对话号与所述呼叫已经结束的第一业务逻辑对应。

5.如权利要求1至3任一所述的业务逻辑处理方法，其特征在于，接收所述内部切换请求后还包括：结束除所述第二有限状态机外的所有与所述呼叫对应的有限状态机的运行，以及结束所述交互逻辑的运行。

6.一种业务逻辑处理装置，其特征在于，包括：

保存单元，用于保存对话表；

7.如权利要求6所述的业务逻辑处理装置，其特征在于，所述第三对话号对应的目的地址包括交互逻辑的地址和所述网元的地址；

所述更新单元，具体用于将与所述第三对话号对应的交互逻辑的地址更新为第二业务逻辑的地址。

8.如权利要求6或7所述的业务逻辑处理装置，其特征在于，所述更新单元，还用于删除所述对话表中与所述第二对话号对应的表项，以及删除与第一对话号对应的表项，所述第一对话号与所述呼叫已经结束的第一业务逻辑对应。

9.如权利要求6或7所述的业务逻辑处理装置，其特征在于，还包括：

结束单元，用于在所述接收单元接收了所述内部切换请求后，结束除所述第二有限状态机外的所有与所述呼叫对应的有限状态机的运行，以及结束所述交互逻辑的运行。

10.一种通信系统，其特征在于，包括如权利要求6至9任一所述的业务逻辑处理装置。