一种业务协同处理装置及方法与流程

文档序号:14612718发布日期:2018-06-05 21:14阅读:377来源:国知局
一种业务协同处理装置及方法与流程

本发明涉及通信领域,更具体地说,涉及智能网中的业务协同处理方法及装置。



背景技术:

由于在原有通信网络中采用智能网技术可向用户提供业务特性强、功能全面、灵活多变的移动新业务,具有很大市场需求,因此,智能网已逐步成为现代通信提供新业务的首选解决方案。智能网的目标是为所有通信网络提供满足用户需要的新业务,包括PSTN、GSM、CDMA等通信网,智能化是通信网络的发展方向。智能网的主要特点就是将交换与业务控制分离,即交换中心只完成基本的接续功能,而在电信网中另设一些新的功能节点,由这些功能节点协同原来的交换中心共同来完成智能业务。

智能网是由程控交换机节点、7号信令网及业务控制计算机构成的电话网,是在现有电话网的基础上发展而来的,是指带有智能的电话网或综合业务数字网。它的网络智能配置于分布在全网中的若干个业务控制点中的计算机上,由软件实现网络智能的控制,以提供更为灵活的智能控制功能。智能网在增加新业务时不用改造端局和交换机,而由电信公司人员甚至用户自己修改软件就能达到随时提供新业务的目的。

目前的智能网业务均是独立运行的,例如一个电话用户通过拨打电话仅能触发一个智能网业务软件为其服务。但在一个智能网中,会有很多业务软件用于提供各种不同的服务,这时如果希望在电话用户拨打电话时对该用户同时提供多种服务,就存在很大困难,需要重新开发一个新业务软件,把多种服务整合到这个新业务软件中。这样用户拨打电话时会触发这个新开发的业务软件来使用多种服务。对多个业务软件进行整合开发需要保证业务软件在具有原有各业务的功能的情况下,还要能够控制原有各业务软件之间的逻辑冲突,是一个耗费时间和人力的工作。而且长期发展下去,一个功能会同时存在于几个业务软件中,如果这个功能需要修改,则含有这个功能的业务软件均需要同步修改、测试、发布,造成了重复的工作,耗费了大量的人力物力。在电信业务日益深入人类生活的同时,智能网需要提供的服务会越来越多,如何合理利用这些业务减少开发工作,成为电信公司亟需解决的难题。

同时由于历史的原因,很多国家、地区以及电信运营商会同时拥有多个制式通信网络,特别是在4G时代,会出现2G、3G、4G网络长期共存的局面。但是由于智能网是原有通信网络的附加网络,智能网的业务软件均是针对固定的网络协议开发而成,所以在多种通信网络共存的环境下,电信运营商如果需要在不同的通信网络下提供相同的服务,只能够开发多套逻辑相同但协议不同的业务软件,这造成了极大的冗余,维护极为不便。



技术实现要素:

有鉴于此,本发明提供了一种业务协同处理装置,包括:

接收模块,用于当接收到交换中心发送的起始信令时,解析所述起始信令以获取至少一个目标业务信息,其中,所述目标业务信息包括业务优先级以及各目标业务的基本信息;

确定模块,用于依据所述业务优先级以及各所述目标业务的基本信息确定各所述目标业务的触发顺序以及对应的触发信息;

触发模块,用于依据所述触发信息依次向业务控制中心发送各所述目标业务对应的反向起始信令以触发各所述目标业务。

可选地,所述触发信息包括所述目标业务的业务键、全局码地址,所述触发模块包括:

会话请求单元,用于向所述业务控制中心发送会话请求以建立第一会话,其中,所述第一会话与协同控制业务关联,所述会话请求携带所述目标业务的触发信息;

反向信令单元,用于通过所述第一会话向所述业务控制中心发送所述目标业务对应的反向起始信令以使所述业务控制中心编码所述反向起始信令并通过第二会话发送编码后的所述第二反向起始信令至所述交换中心;其中,所述第二会话与所述第一会话关联;

触发监控单元,用于判断各所述目标业务对应的反向起始信令是否发送完毕,若是,则会话请求单元停止发送会话请求,若否,则所述会话请求单元继续发送会话请求。

可选地,所述触发信息还包括所述目标业务的协议类型,所述装置还包括:

协议转换模块,用于当所述目标业务的协议类型与所述起始信令的协议类型不同时,对向所述目标业务所在的核心网以及发出所述起始信令的核心网发出的信令进行协议转换,使发出的信令的格式匹配目的核心网的协议类型。

可选地,所述接收模块还用于:

接收各所述目标业务的返回信令。

可选地,所述装置还包括:

信令转发模块,用于当各所述目标业务对应的反向起始信令发送完毕时,依据所述业务优先级依次发送各所述返回信令至所述业务控制中心以使所述业务控制中心。

可选地,所述装置还包括:

信令修改模块,用于当所述返回信令中的被叫号码改变时,依据改变后的被叫号码修改待发送的下一个所述反向起始信令。

可选地,所述装置还包括:

注册管理模块,用于收集各所述目标业务返回的所有事件注册信令并登记注册信息表,向所述交换中心发送综合事件注册信令,接收到事件通知信令后依据注册信息表向各对应的目标业务发送事件通知信令。

本发明还提供一种业务协同处理方法,所述方法包括:

当接收到交换中心发送的起始信令时,解析所述起始信令以获取至少一个目标业务信息,其中,所述目标业务信息包括业务优先级以及各目标业务的基本信息;

依据所述业务优先级以及各所述目标业务的基本信息确定各所述目标业务的触发顺序以及对应的触发信息;

依据所述触发信息依次向业务控制中心发送各所述目标业务对应的反向起始信令以触发各所述目标业务。

可选地,所述触发信息包括所述目标业务的业务键、全局码地址,所述依据所述触发信息依次向业务控制中心发送各所述目标业务对应的反向起始信令以触发各所述目标业务具体包括:

向所述业务控制中心发送会话请求以建立第一会话,其中,所述第一会话与协同控制业务关联,所述会话请求携带所述目标业务的触发信息;

通过所述第一会话向所述业务控制中心发送所述目标业务对应的反向起始信令以使所述业务控制中心编码所述反向起始信令并通过第二会话发送编码后的所述第二反向起始信令至所述交换中心;其中,所述第二会话与所述第一会话关联;

判断各所述目标业务对应的反向起始信令是否发送完毕,若是,则停止发送会话请求,若否,则继续发送会话请求。

可选地,所述触发信息还包括所述目标业务的协议类型,所述方法还包括:

当所述目标业务的协议类型与所述起始信令的协议类型不同时,对向所述目标业务所在的核心网以及发出所述起始信令的核心网发出的信令进行协议转换,使发出的信令的格式匹配目的核心网的协议类型。

可选地,所述方法还包括:

接收各所述目标业务的返回信令。

可选地,所述方法还包括:

当各所述目标业务对应的反向起始信令发送完毕时,依据所述业务优先级依次发送各所述返回信令至所述业务控制中心以使所述业务控制中心。

可选地,所述方法还包括:

当所述返回信令中的被叫号码改变时,依据改变后的被叫号码修改待发送的下一个所述反向起始信令。

可选地,所述方法还包括:

注册管理模块,用于收集各所述目标业务返回的所有事件注册信令并登记注册信息表,向所述交换中心发送综合事件注册信令,接收到事件通知信令后依据注册信息表向各对应的目标业务发送事件通知信令。

本发明提供的业务协同处理装置及方法在接收到起始信令后触发获取协同控制业务,解析起始信令以获取至少一个目标业务信息,依据目标业务信息确定各所述目标业务的触发顺序以及对应的触发信息;依据所述触发顺序及触发信息依次向业务控制中心发送各所述目标业务对应的反向起始信令以触发各所述目标业务。从而,在不增加及升级现有通信网络设备的前提下,通过协同控制业务的触发,能够通过对智能网下不同的业务进行协同处理,实现了一次呼叫启动多项业务的目的,提升了用户体验,同时,通过协同控制业务对其他业务进行触发及管理,也减少了开发人员的维护工作及负担。

【附图说明】

图1是本发明实施例一业务协同处理装置的功能模块图;

图2是本发明实施例一中触发模块的细化功能模块图;

图3是本发明中业务协同处理装置10触发任一目标业务时智能网中及核心网中各网元的交互示意图;

图4时本发明实施例二业务协同处理装置的功能模块图;

图5是本发明中进行跨网通信时智能网中及核心网中各网元一交互示意图;

图6是本发明实施例三业务协同处理装置的功能模块图;

图7是本发明呼叫发起时智能网及核心网中各网元间一信令交互示意图;

图8是本发明实施例四业务协同处理方法的流程图;

图9是本发明实施例四中步骤S803的细化流程图。

【具体实施方式】

为了使本发明的目的、技术方案及优点更加清楚明白,以下结合附图及实施例,对本发明进行进一步详细说明。应当理解,此处所描述的具体实施例仅用以解释本发明,并不用于限定本发明。

以下对本发明中的一些通信缩略语或术语进行统一说明:

SSP:Service Switch Point,业务交换中心;

SCP:Service Control Point,业务控制中心;

MSC:Mobile Switching Center,移动交换中心;

CAMEL:Customized Applications Mobile network Enhanced Logic,移动网络增强逻辑的客户化应用;

MTP3:Message Transfer Part level 3,7号信令消息传递部分第三层;

INAP:INAP Intelligent Network Application Protocol,智能网应用协议;

CAPv2:CAMEL application Part,phase 2,CAMEL第二阶段。

请参阅图1,图1是本发明实施例一业务协同处理装置的功能模块图。图1所示的业务协同处理装置10包括接收模块101、确定模块103以及处罚模块103。本发明中的业务协同处理装置主要应用于智能网中SCP,即作为业务交换中心的计算机上。下面对各功能模块进行详细说明。

接收模块101,用于当接收到交换中心发送的起始信令时,解析所述起始信令以获取至少一个目标业务信息,其中,所述目标业务信息包括业务优先级以及各目标业务的基本信息;

确定模块102,用于依据所述业务优先级以及各所述目标业务的基本信息确定各所述目标业务的触发顺序以及对应的触发信息;

具体的,当用户呼叫通过核心网交换中心例如SSP或MSC发送至SCP时,此时,SCP上的协同控制业务会被触发。在本发明各实施例中,不管用户呼叫的业务为何,只要接收到起始信令(例如InitialDP),都会触发协同控制业务,由业务协同处理装置10处理后续信令。起始指令中一般而言包含了用户需要触发的目标业务信息,包括但不限于业务优先级以及目标业务的基本信息。业务的基本信息包括但不限于业务键、全局码地址(GT地址)、协议类型等。接收模块101接收到起始信令后解析得到上述信息后,确定模块102即可以查找对应的需要触发的目标业务的触发信息以及各个目标业务的触发顺序,此处,触发信息即为业务的基本信息。

触发模块103,用于依据所述触发顺序及触发信息依次向业务控制中心发送各所述目标业务对应的反向起始信令以触发各所述目标业务。

具体的,触发模块触发各目标业务时,遵循各目标业务的触发顺序。触发模块根据每一个目标业务的触发信息,发送反向起始信令至业务控制中心,业务控制中心对该反向起始信令进行编码后,将其发送给核心网,核心网依据GT地址进行路由,最终将该反向起始信令发送至目标业务所在的目标SCP,目标SCP解码该反向起始信令后,目标业务将被触发。

需要说明的是,在智能网等通信网络上的信令协议,均具有方向性这一明显特征。例如智能网常用的CAMEL信令协议中,InitialDP(呼叫上报)操作一般只能从核心网发送给SCP,因此SCP一般只能对信令进行编码或解码操作,不支持既编码又解码。而在本发明各实施例中,可以使SCP将InitialDP操作(反向起始信令)发送回核心网,由核心网路由到目标SCP,因此,本发明SCP对所有的信令操作均支持编码与解码操作,对于每一个信令操作,既可以编码后发送,也可以接收后解码。

进一步的,请同时参考图2及图3,图2是触发模块103的细化功能模块图,图3是本发明中业务协同处理装置10触发任一目标业务时,智能网中及核心网中各网元的交互图。触发模块103具体包括会话请求单元1031、反向信令单元1032以及触发监控单元1033。以下对各细化功能模块进行说明:

会话请求单元1031,用于向所述业务控制中心发送会话请求以建立第一会话,其中,所述第一会话与协同控制业务关联,所述会话请求携带所述目标业务的触发信息;

反向信令单元1032,用于通过所述第一会话向所述业务控制中心发送所述目标业务对应的反向起始信令以使所述业务控制中心编码所述反向起始信令并通过第二会话发送编码后的所述反向起始信令至所述交换中心;其中,所述第二会话与所述第一会话关联;所述交换中心依据所述目标业务的业务键、全局码地址将所述反向起始指令发送至所述目标业务。

触发监控单元1033,用于判断各所述目标业务对应的反向起始信令是否发送完毕,若是,则会话请求单元停止发送会话请求,若否,则所述会话请求单元继续发送会话请求。

以下结合图3对触发目标业务的过程进行说明:

当需要触发一个普通智能网业务时,需要获取这个目标业务的基本信息,比如业务键、GT地址、协议类型等,这些信息都已经通过上述接收模块101以及确定模块102实现。会话请求单元1031将这些信息发送给SCP,同时请求建立会话,如图3中所示,会话请求单元1031发出会话请求RequestDialogID并携带相关参数。SCP将根据这些信息建立一个与协同控制业务关联的反向会话(第一会话),通过RequestDialogIDResponse返回会话参数。同时也会根据这些信息,与核心网中的MSC/SSP建立一个会话(第二会话,图中未),并将这两个会话进行关联。第一会话建立后,反向信令单元1032通过该会话发送用于触发目标业务的反向起始信令(图中intialIDP)给SCP,由SCP编码该反向起始信令,并连同上述GT地址一起编码为MTP3的消息一起通过第二会话发送给MSC/SSP,MSC/SSP根据MTP3协议解析该消息,根据该消息中的GT地址进行路由,目的SCP从核心网接收到该MTP3消息后,解码为起始信令后触发目标业务。至此,实现了一个目标业务的触发。后续,目标业务回复的信令(如接续信令connect)将按原路返回,核心网仍通过第二会话将该返回信令发送给SCP,SCP查找关联对话后,即会通过第一会话将该返回信息发送给业务协同处理装置10。

触发监控单元1033持续监控各目标业务是否均被触发,在所有目标业务对应的反向起始信令未发送完之前,会话请求单元1031与反向信令单元1032将持续上述业务处触发过程,直至所有目标业务都被触发完毕。

本实施例提供的业务协同处理装置,在接收到起始信令后,解析获取需要触发的各目标业务的触发信息以及触发顺序,依次向SCP发送反向起始指令,由SCP将各反向起始指令发送至各目标SCP以触发各目标业务。从而,用户通过一个呼叫即可依次触发多个业务,而智能网也无需增加或升级其他网络设备即可实现多个业务的协同处理,在提升用户体验的同时也减少了开发人员的维护负担。

请参阅图4,图4是本发明实施例二业务协同处理装置的功能模块图。在本实施例中,所述业务协同处理装置与实施例一的区别仅在于:实施例一中的接收模块101,确定模块102以及触发模块103外,在本实施例中,业务协同处理装置10还包括:

协议转换模块104,用于当所述目标业务的协议类型与所述起始信令的协议类型不同时,对向所述目标业务所在的核心网以及发出所述起始信令的核心网发出的信令进行协议转换,使发出的信令的格式匹配目的核心网的协议类型。

具体的,同进行跨网通信时,用户所在核心网与其需要的业务所在的核心网其采用的协议类型并不一致,此时,协议转换模块需要对发出和接收的信令进行协议转换,使信令格式与其目的核心网协议类型匹配。请参考图5,所示是本发明中进行跨网通信时跨网通信时智能网中及核心网中各网元一交互示意图。如图5所示,业务协同处理装置10所连接的核心网1(即图中左侧发起呼叫的MSC/SSP所在的核心网)采用CAPv2协议,而目标业务所在的核心网2(即图中右侧目标SCP旁的MSC/SSP所在的核心网)采用INAP协议,两者信令协议类型不一致,此时,SCP解码过后的initialIDP起始信令为CAPv2格式,协议转换模块104根据目标业务基本信息可以确认其协议类型为INAP,因此,在发出触发相应目标业务的反向起始信令时,会根据目标业务的协议类型对信令协议进行转换,使最终发向目标业务所在核心网2的反向起始信令的格式为INAP,与核心网2匹配,如图中①处即体现了此协议转换过程。同样,如果业务协同处理装置10从SCP接收到的返回信令(例如接续信令和释放信令)并不是呼叫所在核心网1的信令协议类型,协议转换模块104会主动转换接收到的返回信令的格式再处理,图中②处所示,由目标业务发送的接续信令connect沿原路径返回至业务协同处理装置10时,其格式为INAP,该指令的目的地最终需要返回至呼叫所在核心网1,此时,协议转换模块104主动将其转换为CAPv2格式再发送给SCP,使该返回信令符合其目的核心网1的协议类型。

本实施例中,当进行跨网通信时,业务协同处理装置依据目的核心网的协议类型对发出的信令的协议类型进行转换,避免了跨网通信时协议不兼容问题。

请参阅图6,图6所示是本发明实施例三业务协同处理装置的功能模块图。在本实施例中,所述业务协同处理装置与实施例二的区别仅在于:

在本实施例中,接收模块101还用于接收各所述目标业务的返回信令,业务协同处理装置10还包括:

信令转发模块105,用于当各所述目标业务对应的反向起始信令发送完毕时,依据所述业务优先级依次发送各所述返回信令至所述业务控制中心。

具体的,请进一步参考图7所示,所示是本发明中呼叫发起时智能网及核心网中各网元间一信令交互示意图,以用户发起呼叫一次触发两个业务为例,MSC/SSP发出起始信令initialIDP后,触发模块103根据业务优先级先发出目标业务1的起始信令,如图中携带业务键参数servicekey=1的反向起始信令initialIDP以触发目标业务1,在业务协同处理装置10发出目标业务2的起始信令(图中携带业务键参数servicekey=2的反向起始信令initialIDP)之前,接收模块101已经接收到了目标业务1返回的接续信令connect,此时,为保证可以按照业务优先级顺序触发目标业务,信令转发模块105并不处理目标业务1返回的接续信令connect,触发模块103继续读取下一个需要触发的目标业务,根据业务优先级先发出目标业务2的起始信令,在目标业务2的起始信令发出之后,此时,信令转发模块105对于接收到的各个返回信令,包括来自目标业务1的接续信令connect以及来自目标业务2的接续信令connect,将按照预置的冲突处理策略进行处理,进一步的,根据业务优先级处理,优选处理业务优先级高的接续信令,将该信令发送至SCP处由SCP转发MSC/SSP处。

由此,进一步保证了各个目标业务的顺序触发,同时通过业务优先级避免了多个信令处理时的冲突。

进一步的,在本实施例中,业务协同处理装置10还包括:

信令修改模块106,用于当所述返回信令中的被叫号码改变时,依据改变后的被叫号码修改待发送的下一个所述反向起始信令。

具体的,在顺序触发目标业务时,信令修改模块106将一些必要的信息的改变在业务之间进行传递,例如,当被叫号码与主叫号码处于同一个集团网时,当触发短号集群网业务后即该目标业务的返回信令(例如接续信令或释放信令)中被叫号码会发生变化,例如,变为集群网短号,此时,信号修改模块106可以根据新的被叫号码修改未发送的其他目标业务的反向起始信号。具体方式包括但不限于:1)将前一个目标业务的接续信令中的被叫号码作为后一个即将触发的目标业务的反向起始信令中的被叫号码;2)将前一个目标业务接续信令中的被叫号码加特定前缀作为后一个即将触发的目标业务的起始信令中的被叫号。由此,通过信令的修改实现了目标业务触发中的信息传递。

进一步的,在本实施例中,业务协同处理装置10还包括:

注册管理模块107,用于收集各所述目标业务返回的所有事件注册信令并登记注册信息表,向所述交换中心发送综合事件注册信令,接收到事件通知信令后依据登记注册信息表向各对应的目标业务发送事件通知信令。

具体的,普通的智能网业务通过SCP向核心网发送事件注册信令(如RequestReportBCSMEvent),来向核心网预订事件通知,当预订的事件发生后,核心网会通过SCP通知业务,然后业务通过SCP向核心网发送信令,指导核心网完成对该事件的处理。在本发明中,各目标业务都由业务协同处理装置10协同触发,因而,其事件注册也有业务协同处理装置10协同处理。触发各个目标业务后,注册管理模块107需要收集所有目标业务发送的事件注册信令,并对这些信令进行合并,建立注册信息表,登记各需要注册的事件以及注册该事件的目标业务。登记完毕后,注册管理模块107仅发送一个事件注册信令到核心网,该事件注册信令中包含了所有目标业务需要注册的事件。在注册的事件发生时,核心网上报事件通知信令,此时,注册管理模块107要查询所有注册该事件的目标业务,并对每个注册该事件的目标业务发送反向事件通知信令,由SCP将该事件通知信令通过核心网路由到对应的目标业务。由此,实现了注册事件的合并管理。

请参考图8,所示是本发明实施例四业务协同处理方法的流程图。所示业务协同处理方法主要应用于智能网中SCP,即作为业务交换中心的计算机上,通过上述各实施例的业务协同处理装置10实现。

在本实施例中,所述方法包括步骤:

S801,当接收到交换中心发送的起始信令时,解析所述起始信令以获取至少一个目标业务信息,其中,所述目标业务信息包括业务优先级以及各目标业务的基本信息;

S802,依据所述业务优先级以及各所述目标业务的基本信息确定各所述目标业务的触发顺序以及对应的触发信息;

具体的,当用户呼叫通过核心网交换中心例如SSP或MSC发送至SCP时,此时,SCP上的协同控制业务会被触发。在本发明各实施例中,不管用户呼叫的业务为何,只要接收到起始信令(例如InitialDP),都会触发协同控制业务,由业务协同处理装置10处理后续信令。起始指令中一般而言包含了用户需要触发的目标业务信息,包括但不限于业务优先级以及目标业务的基本信息。业务的基本信息包括但不限于业务键、全局码地址(GT地址)、协议类型等。接收模块101接收到起始信令后解析得到上述信息后,确定模块102即可以查找对应的需要触发的目标业务的触发信息以及各个目标业务的触发顺序,此处,触发信息即为业务的基本信息。

S801,依据所述触发顺序及触发信息依次向业务控制中心发送各所述目标业务对应的反向起始信令以触发各所述目标业务。

具体的,触发模块103触发各目标业务时,遵循各目标业务的触发顺序。触发模块103根据每一个目标业务的触发信息,发送反向起始信令至业务控制中心,业务控制中心对该反向起始信令进行编码后,将其发送给核心网,核心网依据GT地址进行路由,最终将该反向起始信令发送至目标业务所在的目标SCP,目标SCP解码该反向起始信令后,目标业务将被触发。

需要说明的是,在智能网等通信网络上的信令协议,均具有方向性这一明显特征。例如智能网常用的CAMEL信令协议中,InitialDP(呼叫上报)操作一般只能从核心网发送给SCP,因此SCP一般只能对信令进行编码或解码操作,不支持既编码又解码。而在本发明各实施例中,可以使SCP将InitialDP操作(反向起始信令)发送回核心网,由核心网路由到目标SCP,因此,本发明SCP对所有的信令操作均支持编码与解码操作,对于每一个信令操作,既可以编码后发送,也可以接收后解码。

进一步的,请同时参考图9及图3,图9是步骤S803的细化流程图,图3是本发明中业务协同处理装置10触发任一目标业务时,智能网中及核心网中各网元的交互图。步骤S803具体包括以下步骤:

S8031,向所述业务控制中心发送会话请求以建立第一会话,其中,所述第一会话与协同控制业务关联,所述会话请求携带所述目标业务的触发信息;

S8032,通过所述第一会话向所述业务控制中心发送所述目标业务对应的反向起始信令以使所述业务控制中心编码所述反向起始信令并通过第二会话发送编码后的所述反向起始信令至所述交换中心;其中,所述第二会话与所述第一会话关联;所述交换中心依据所述目标业务的业务键、全局码地址将所述反向起始指令发送至所述目标业务。

S8033,判断各所述目标业务对应的反向起始信令是否发送完毕,若是,则停止发送会话请求,若否,则返回步骤S8031。

以下结合图3对触发目标业务的过程进行说明:

当需要触发一个普通智能网业务时,需要获取这个目标业务的基本信息,比如业务键、GT地址、协议类型等,这些信息都已经通过上述接收模块101以及确定模块102实现。会话请求单元1031将这些信息发送给SCP,同时请求建立会话,如图3中所示,会话请求单元1031发出会话请求RequestDialogID并携带相关参数。SCP将根据这些信息建立一个与协同控制业务关联的反向会话(第一会话),通过RequestDialogIDResponse返回会话参数。同时也会根据这些信息,与核心网中的MSC/SSP建立一个会话(第二会话,图中未),并将这两个会话进行关联。第一会话建立后,反向信令单元1032通过该会话发送用于触发目标业务的反向起始信令(图中intialIDP)给SCP,由SCP编码该反向起始信令,并连同上述GT地址一起编码为MTP3的消息一起通过第二会话发送给MSC/SSP,MSC/SSP根据MTP3协议解析该消息,根据该消息中的GT地址进行路由,目的SCP从核心网接收到该MTP3消息后,解码为起始信令后触发目标业务。至此,实现了一个目标业务的触发。后续,目标业务回复的信令(如接续信令connect)将按原路返回,核心网仍通过第二会话将该返回信令发送给SCP,SCP查找关联对话后,即会通过第一会话将该返回信息发送给业务协同处理装置10。

触发监控单元1033持续监控各目标业务是否均被触发,在所有目标业务对应的反向起始信令未发送完之前,会话请求单元1031与反向信令单元1032将持续步骤S8031及S8032,直至所有目标业务都被触发完毕。

本实施例提供的业务协同处理方法,在接收到起始信令后,解析获取需要触发的各目标业务的触发信息以及触发顺序,依次向SCP发送反向起始指令,由SCP将各反向起始指令发送至各目标SCP以触发各目标业务。从而,用户通过一个呼叫即可依次触发多个业务,而智能网也无需增加或升级其他网络设备即可实现多个业务的协同处理,在提升用户体验的同时也减少了开发人员的维护负担。

本发明实施例五进一步提出另一种业务协同处理方法。在本实施例中,所述业务协同处理方法与实施例四的区别仅在于:在本实施例中,所述方法还包括以下步骤:

当所述目标业务的协议类型与所述起始信令的协议类型不同时,对向所述目标业务所在的核心网以及发出所述起始信令的核心网发出的信令进行协议转换,使发出的信令的格式匹配目的核心网的协议类型。

具体的,同进行跨网通信时,用户所在核心网与其需要的业务所在的核心网其采用的协议类型并不一致,此时,协议转换模块需要对发出和接收的信令进行协议转换,使信令格式与其目的核心网协议类型匹配。请参考图5,所示是本发明中进行跨网通信时跨网通信时智能网中及核心网中各网元一交互示意图。如图5所示,业务协同处理装置10所连接的核心网1(即图中左侧发起呼叫的MSC/SSP所在的核心网)采用CAPv2协议,而目标业务所在的核心网2(即图中右侧目标SCP旁的MSC/SSP所在的核心网)采用INAP协议,两者信令协议类型不一致,此时,SCP解码过后的initialIDP起始信令为CAPv2格式,协议转换模块104根据目标业务基本信息可以确认其协议类型为INAP,因此,在发出触发相应目标业务的反向起始信令时,会根据目标业务的协议类型对信令协议进行转换,使最终发向目标业务所在核心网2的反向起始信令的格式为INAP,与核心网2匹配,如图中①处即体现了此协议转换过程。同样,如果业务协同处理装置10从SCP接收到的返回信令(例如接续信令和释放信令)并不是呼叫所在核心网1的信令协议类型,协议转换模块104会主动转换接收到的返回信令的格式再处理,图中②处所示,由目标业务发送的接续信令connect沿原路径返回至业务协同处理装置10时,其格式为INAP,该指令的目的地最终需要返回至呼叫所在核心网1,此时,协议转换模块104主动将其转换为CAPv2格式再发送给SCP,使该返回信令符合其目的核心网1的协议类型。

本实施例中,当进行跨网通信时,业务协同处理装置依据目的核心网的协议类型对发出的信令的协议类型进行转换,避免了跨网通信时协议不兼容问题。

本发明实施例六进一步提出另一种业务协同处理方法。在本实施例中,所述业务协同处理装置与实施例五的区别仅在于:

在本实施例中,所述方法还包括以下步骤:

接收各所述目标业务的返回信令;

当各所述目标业务对应的反向起始信令发送完毕时,依据所述业务优先级依次发送各所述返回信令至所述业务控制中心。

具体的,请进一步参考图7所示,所示是本发明中呼叫发起时智能网及核心网中各网元间一信令交互示意图,以用户发起呼叫一次触发两个业务为例,MSC/SSP发出起始信令initialIDP后,触发模块103根据业务优先级先发出目标业务1的起始信令,如图中携带业务键参数servicekey=1的反向起始信令initialIDP以触发目标业务1,在业务协同处理装置10发出目标业务2的起始信令(图中携带业务键参数servicekey=2的反向起始信令initialIDP)之前,接收模块101已经接收到了目标业务1返回的接续信令connect,此时,为保证可以按照业务优先级顺序触发目标业务,信令转发模块105并不处理目标业务1返回的接续信令connect,触发模块103继续读取下一个需要触发的目标业务,根据业务优先级先发出目标业务2的起始信令,在目标业务2的起始信令发出之后,此时,信令转发模块105对于接收到的各个返回信令,包括来自目标业务1的接续信令connect以及来自目标业务2的接续信令connect,将按照预置的冲突处理策略进行处理,进一步的,根据业务优先级处理,优选处理业务优先级高的接续信令,将该信令发送至SCP处由SCP转发MSC/SSP处。

由此,进一步保证了各个目标业务的顺序触发,同时通过业务优先级避免了多个信令处理时的冲突。

进一步的,在本实施例中,所述方法还包括以下步骤:

当所述返回信令中的被叫号码改变时,依据改变后的被叫号码修改待发送的下一个所述反向起始信令。

具体的,在顺序触发目标业务时,信令修改模块106将一些必要的信息的改变在业务之间进行传递,例如,当被叫号码与主叫号码处于同一个集团网时,当触发短号集群网业务后即该目标业务的返回信令(例如接续信令或释放信令)中被叫号码会发生变化,例如,变为集群网短号,此时,信号修改模块106可以根据新的被叫号码修改未发送的其他目标业务的反向起始信号。具体方式包括但不限于:1)将前一个目标业务的接续信令中的被叫号码作为后一个即将触发的目标业务的反向起始信令中的被叫号码;2)将前一个目标业务接续信令中的被叫号码加特定前缀作为后一个即将触发的目标业务的起始信令中的被叫号。由此,通过信令的修改实现了目标业务触发中的信息传递。

进一步的,在本实施例中,所述方法还包括以下步骤:

注册管理模块107,用于收集各所述目标业务返回的所有事件注册信令并登记注册信息表,向所述交换中心发送综合事件注册信令,接收到事件通知信令后依据登记注册信息表向各对应的目标业务发送事件通知信令。

具体的,普通的智能网业务通过SCP向核心网发送事件注册信令(如RequestReportBCSMEvent信令),来向核心网预订事件通知,当预订的事件发生后,核心网会通过SCP通知业务,然后业务通过SCP向核心网发送信令,指导核心网完成对该事件的处理。在本发明中,各目标业务都由业务协同处理装置10协同触发,因而,其事件注册也有业务协同处理装置10协同处理。触发各个目标业务后,注册管理模块107需要收集所有目标业务发送的事件注册信令,并对这些信令进行合并,建立注册信息表,登记各需要注册的事件以及注册该事件的目标业务。登记完毕后,注册管理模块107仅发送一个事件注册信令到核心网,该事件注册信令中包含了所有目标业务需要注册的事件。在注册的事件发生时,核心网上报事件通知信令,此时,注册管理模块107要查询所有注册该事件的目标业务,并对每个注册该事件的目标业务发送反向事件通知信令,由SCP将该事件通知信令通过核心网路由到对应的目标业务。由此,实现了注册事件的合并管理。

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

当前第1页1 2 3 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1