背景技术
近年来随着技术的发展,人们对业务的要求不断提高,传统的、基于单一网络的业务提供机制已不再满足人们的需要,而综合化的、个性化的融合业务在这种背景下应运而生。可以说,在三网融合的过程中,业务融合的需求以及技术的发展的需要成为了三网融合的直接动力。
融合业务主要是指基于电信网、计算机网、和有线电视网提供的高层应用融合的业务,其表现为技术上趋向一致,网络层上可以实现互联互通,形成无缝覆盖,业务层上互相渗透和交叉。为了支持上述要求,现在提出了新一代业务运行管控协同支撑环境。它作为一个完整的业务提供系统,包含了从业务生成、运行、控制到访问。作为新一代业务运行管控协同支撑环境的重要组成部分和支撑部分,它的功能可以直接影响到整个系统的功能实现。在实现融合业务过程中,会话控制系统是重要保障,它是整个融合业务提供系统的支撑。
业务触发模块是实现融合业务的重要组成部分,本文首先在介绍现有的业务触发机制的基础上分析了其存在的问题,然后对现有的国内外一些业务触发研究做了分析和比较,并提出了一种新的基于状态的业务触发机制。它可以根据业务之间的关系、业务所处在状态、以及其它各种和业务触发相关的信息来动态地调整业务触发的顺序。该机制可以有效地避免现有业务触发的弊端,提高业务触发的灵活性和动态性。
会话控制系统作为实现融合业务环境的会话控制和管理部分,承担着地址解析/翻译功能、会话建立、维护修改和释放等整个生命周期管理功能等,它在新一代业务运行管控协同支撑环境中的位置如图1所示:
从图1可以看出,新一代业务运行管控协同支撑环境主要包括四层,从下到上依次是:
物理网络层(Physics Networ Layer):主要指承载网,包含电信网、互联网、和广电网在内的各种物理网络,承载网络提供了相应网络的基础网络设施和各种能力服务,基础网络设施包括网络连接、QoS保障机制、终端接入、用户接入、用户数据等,能力服务包括媒体服务器、流媒体服务器、会议服务器等网络设备;
适配层(Adapter Layer):屏蔽各个具体承载网络的异构性,为上层服务提供统一的接口,方便上层服务(如服务层各功能实体)对承载网的调用;
服务控制层(Service Control Layer):提供各种个性化、丰富的媒体业务融合所需的可复用的服务组件,服务具备开放的接口供业务层组合各种业务,主要包含内容服务器、数据存储及分发服务和会话服务;
业务层(Application Layer):按照业务逻辑将服务层提供的服务组合成多样化的业务,根据服务状态和性能需求对服务的部署进行动态调优,通过业务层的管控和运行协同呈现给用户使用;
会话服务控制系统处于整个新一代业务运行管控协同支撑环境的服务控制层,向下调用承载网适配器提供的统一接口和网络中的其它功能实体进行通信,建立会话,包括用户终端、应用服务器等,向上调用业务运行协同平台提供的业务,完成用户的业务触发,使用户能享受自身所订购的业务。本系统类似于IP多媒体子系统(Ip Multimedia Subsystem,IMS)中的呼叫会话控制功能实体(CallSession Control Function,CSCF)。但本系统是面向三网融合的,结合它在实现融合业务体系中的角色以及需要提供的功能,相对于IMS中的服务-CSCF(serving-CSCF,S-CSCF),本系统是一个相对轻量级的CSCF,只具有CSCF的部分功能,例如它不需要对用户进行认证,不需要监管注册定时器等。
呼叫服务管理(Calling Servicing Management CSM)模块的功能是完成在呼叫、订阅、通知过程中提供业务触发、资源管理、号码分析等呼叫相关的服务。从本质上讲,呼叫服务功能就是状态机在处理状态转移过程中调用的服务,这些服务是完成SCS功能需求的关键,下面将主要介绍业务触发模块。
业务触发是系统的重要功能之一,是实现融合业务的关键部分。在务触发过程中,初始过滤集(initial Filter Criteria,iFC)起了重要作用。业务触发表示根据用户的会话请求消息,结合用户所订购的业务配置信息,确定当前用户的会话初始请求是否满足触发业务的条件,若满足,触发此业务,若不满足,进行正常的会话建立流程,
从图2可以看出,现有业务触发原理就是按照用户服务配置数据中的iFC,对接收到的会话初始请求消息进行规则匹配,并返回逻辑匹配结果,若为真,则触发此业务,否则继续匹配优先较低的业务,或者进行其他的处理,直到所有的业务都匹配完成。在匹配的过程中,匹配的顺序完全依赖于iFC中的优先级,通过分析现有业务触发原理,不难发现它具有以下几个弊端:
静态的业务触发顺序:业务的触发的优先级是完全保存在iFC中,无法根据业务的运行状态、会话的进展进行动态的触发;
有限的表达能力:iFC只能按照规定的优先级顺序触发AS,实现简单的业务组合,而对于实现复杂的业务组合则无能为力,例如Presence业务和补充业务有效结合起来,根据用户不同Presence状态调用不同的补充业务。
目前,在涉及业务触发机制方面的研究偏少,而且都主要偏重于如何提高业务触发效率,如何减轻业务触发功能对整个会话控制系统的负载,而对如何提高业务触发机制的灵活性方面却少有研究。
发明内容
为了能提高触发业务的灵活性,降低实现组合业务的难度,在实现该功能模块的时候,本发明实施例采用了基于业务状态的业务触发机制(serviceStatebased Triggering Mechanism,SSTM)。SSTM的核心是通过获取业务的运行状态和一些额外的辅助信息,再结合业务的优先级、动态地控制需要触发的业务顺序。
为了解决上述问题,本发明提出了一种基于三网融合的会话控制系统,包括:
用户业务信息管理模块,用于负责管理IPser模块解析出的用户业务信息;
业务配置信息解析模块,用于负责从用户业务配置文件中解析出各个信息,为后续的业务触发、会话控制提供信息支持;
业务状态信息操作模块,用于负责对SIP消息中的可扩展信息进行操作;;
触发控制模块,用于负责根据其它模块提供的业务信息,按照业务出触发逻辑,完成业务匹配触发功能。
所述用户业务信息管理模块还同时支持添加、维护、更新、修改操作。
所述业务配置信息解析模块包括:
TP解析模块,用于负责解析出每个业务的所有触发点信息;
策略逻辑解析模块,用于负责解析决定这个业务触发顺序的控制逻辑,包括业务触发优先级、业务优先触发状态条件信息,将解析的信息供触发策略模块在决定业务触发顺序的时候调用;
业务信息解析模块:负责解析与该iFC相关的业务信息,提供业务的AS所在的地址,为会话请求的路由、后续业务触发提供信息支持。
所述业务状态信息操作模块包括:
状态信息提取模块,用于负责提取可用与决定业务触发顺序的状态信息,此类信息是指接收到的,并需要进行实时提取的会话消息;
状态信息封装模块,用于负责根据业务触发需求,将一些必要的信息封装到会话消息中,供系统或网络中其它功能实体使用。
所述触发控制模块包括:
规则引擎模块,用于负责根据iFC中的业务触发信息,匹配并判断此会话请求是否满足业务触发要求;
触发策略模块,用于负责根据iFC中的业务触发顺序控制信息和相关业务状态信息来决定业务触发的顺序;
触发执行模块,用于负责完成业务的触发工作,提供业务触发执行环境。
本发明实施例有如下有益效果:
动态的业务触发顺序:一般的业务触发顺序只由业务的优先级来决定,并且这个优先级是保存在用户的iFC中,这使得业务的触发顺序具有一定的静态性,不方便根据业务的执行状态实时调整业务的执行顺序,而SSTM可以根据一些辅助信息,如业务状态而实时地调整业务的触发顺序,提高业务触发的动态性;
灵活的复杂组合业务实现:基于状态的业务触发,可以实时地根据业务的实际运行情况,动态地调整业务的触发顺序,这正是实现组合业务的一个前提条件。例如实现呈现业务与补充业务的组合业务,用户当前的不同状态决定了调用不同的补充业务,SSTM正好满足这个需求;
便捷的服务间通信:提供各个服务的服务器在逻辑上都是独立的功能实体,它们之间没有固定的通信接口,故服务与服务之间如果需要交流信息的话,可以通过扩展的SIP消息进行通信,前提是服务在执行逻辑的同时,可以解析此SIP消息。
具体实施方式
下面将结合本发明实施例中的附图,对本发明实施例中的技术方案进行清楚、完整地描述,显然,所描述的实施例仅仅是本发明一部分实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例,都属于本发明保护的范围。
为了实现SSTM,需要引进用户业务触发管理功能模块(User ServiceTriggering Manager,USTM),USTM模块架构如图3所示,图3中每个功能模块的具体介绍如下:
用户业务信息管理模块(User Service Info Manager,USIM):负责管理IPser模块解析出的用户业务信息,同时支持添加、维护、更新、修改等操作;
业务配置信息解析模块(Service Configuration Info Parser,SCIP):负责从用户业务配置文件中解析出各个信息,为后续的业务触发、会话控制等模块提供信息支持,它主要包括下面三个部分:解析模块(TP Info Parser,TPIPser):负责解析出每个业务的所有触发点信息,规则引擎模块在匹配一个会话请求是否触发业务的时候需要利用此模块解析出的信息;策略逻辑解析模块(Policy LogicParser,PLPser):负责解析决定这个业务触发顺序的控制逻辑,包括业务触发优先级、业务优先触发状态条件等信息,该模块解析的信息主要供触发策略模块在决定业务触发顺序的时候调用;业务信息解析模块:负责解析与该iFC相关的业务信息,如提供业务的AS所在的地址等,为会话请求的路由、后续业务触发提供信息支持;
业务状态信息操作模块(Service State Info Operation,SSIO):SSTM不同与传统的业务触发机制主要体现在多个SSIO模块。SSIO负责对SIP消息中的可扩展信息进行操作,SSIO主要包括两个子功能模块:状态信息提取(State InfoParse,SInfoParse):负责提取可用与决定业务触发顺序的状态信息,此类信息是指接收到的,并需要进行实时提取的会话消息;.状态信息封装(State Info Pack,SInfoPack):负责根据业务触发需求,将一些必要的信息封装到会话消息中,供系统或网络中其它功能实体使用;
触发控制模块(Service Triggering Control,STC):负责根据其它模块提供的业务信息,按照业务出触发逻辑,完成业务匹配触发功能,该模块主要包括下面三个部分:规则引擎模块(Rule Engine,RE):负责根据iFC中的业务触发信息,匹配并判断此会话请求是否满足业务触发要求;.触发策略模块(ServiceTriggering Policy Engine,STPE):负责根据iFC中的业务触发顺序控制信息和从其它模块提供的相关业务状态信息来决定业务触发的顺序;触发执行模块(Service Triggering Execution,STE):负责完成业务的触发工作,提供业务触发执行环境,比如修改会话请求中的路由信息等;
图3中,SSTM模块内部主要有3个接口,它们的定义介绍分别如下:
USIM模块与IPser模块之间的调用接口:USIM模块需要通过该接口调用IPser模块提供的信息解析功能,将用户的业务信息从原始的信息格式转化成STC模块需要的格式;
USIM模块与STC模块之间的调用接口:STC在完成业务触发功能的时候,需要通过该接口调用USIM中保存的用户业务信息,根据业务触发逻辑,完成业务触发控制;
IPser模块与STC模块之间的调用接口:STC在触发业务的过程中,输入信息不全来自于USIM模块,有些是需要根据实时会话状态信息,即会话消息中携带的信息,这时就需要通过该接口来完成会话消息的解析和信息的提取;
iFC在本质上是由许多业务触发点(SPT)通过逻辑运算组成正则表达式,在系统中是以XML的格式存在,其中每个SPT均有特定的标签标识。一般情况下,SPT由SIP消息中的5个部分组成,分别如下:
会话情形:有三种可能的值,即起始(originating)、终止(Terminating)、终止未注册(Termination_Unregistered),指明过滤器是否应该被处理起始、终止、终止未注册的终端用户服务的SCS所使用,起始情形指SCS服务主叫时,终止情形是指SCS服务被叫时;
RequestURI的值:表示该请求所指向的资源,如newsopenims.test.eom;
SIP消息的请求方法:表示该请求的类型,即method,如INVITE/MESSAG等;
SIP消息的头域的值:包含与该请求相关的信息,一个服务点触发器可基于任何SIP头的是否出现,或基于任何SIP头的内容,内容的值是一个字符串,可用一个正则表达式来表示,如from,to等;
会话描述:定义针对SIP方法体内的任何SDP字段内容的服务点触发器,正则表达式可用来匹配该触发器;
实现SCS的业务触发功能,本质上主要是实现下面两个任务:
通过用户公共身份,获取用户所有的业务订购信息,解析以XML格式保存的iFC中的格式化数据,并生成判断规则的正则表达式;
解析收到的SIP消息中的检测点值,根据优先触发规则,对规则进行匹配,并返回逻辑结果。
该部分主要介绍几个SSTM在业务触发过程中的几个关键流程,包括业务信息解析流程,业务触发流程。
业务信息解析流程
业务信息解析的过程实际上就是完成用户配置文件与系统应用程序对象两种不同数据类型之间的映射,并提供数据类型之间映射接口,实现系统应用程序通过对对象的修改,完成对iFC内容的修改。总的来说,业务信息解析主要包括两个方面的功能,一是从用户业务集iFC中提取业务优先级、业务执行策略和业务触发正则表达式,二是根据需求修改iFC中相关参数,如业务优先级等;
业务信息解析主要用在一下几个场景下:当系统接收到一条会话初始请求的SIP消息时,MP模块从SIP中获取用户身份,如果发现内存中不存在该用户相关业务信息的时,则从数据库中读取该用户业务数据的保存位置,调用SCIPser模块完成对用户所有iFC解析,将iFC转化成应用程序规定的对象,并将此对象和用户对象关联起来,实现通过用户对象可以查询用户业务订购信息,见图4所不:
当用户申请了新的业务、或者想对原来的业务信息进行更新时,MP会调用SCIPser模块将用户所做的修改完全并永久地保存到用户的iFC中去;
当从底层接收到一条会话消息时,CC(Calling Control)模块判断此条消息是否属于当前存在的某条会话实例,若是,再根据该会话实例的状态和会话控制逻辑进行处理,若不是,则说明是一条会话初始请求,则调用USIM模块来查询是否有此用户的相关信息;
USIM模块发现没有此用户相关信息,则调用DA模块来查询数据库中保存的此用户相关信息,并返回此用户的所有业务信息;
USIM模块根据DA模块返回的用户信息调用SCIPser模块来解析此用户的所有业务信息,包括业务触发策略,业务匹配规则,并将解析出来的信息添加到用户的对象实例中;
根据正常流程,进行后续的操作流程;
触发控制流程
触发控制是指根据会话请求消息,结合用户业务配置信息,按照业务优先级顺序逐个匹配触发用户业务的过程,它主要包括两个过程:
确定业务触发顺序:该过程以iFC的优先级,业务状态优先触发信息,结合会话请求消息中的Service_State信息为输入,调用S化模块,完成确定业务触发顺序的功能;
检测会话请求是否满足业务触发条件:该过程以iFC中仰信息映射成的触发规则为判断依据,以会话请求消息中相关域值为输入,确定此消息是否满足触发该业务的条件;
详细的业务触发控制流程如图5所示,这里不再重复,图5的流程过程实现如下:
STE模块调用STPE模块获取业务触发序列号;
STPE模块调用SInfoParser模块解析会话请求中携带的业务状态信息;
STPE模块调用USIM模块获取保存的用户业务触发顺序信息;
STPE根据获取的信息,执行策略逻辑,并向STE返回业务触发序列;
STE模块根据业务序列调用RE模块匹配该业务的触发规则;
RE模块通过USIM模块获取该业务触发规则信息,执行匹配规则,并向STE模块返回结果;
STE模块根据RE模块返回的结果执行后续的触发控制流程;
通过结合一个业务触发流程来说明业务触发模块中各个子模块是如何在一起协同工作的,以及他们之间的协作关系。
在这个例子中,假设用户定义了三个业务,S1、S2和S3,其中S1的执行状态决定了S2和S3的触发顺序。若S1返回的状态信息为Running,则先触发S2,否则,先触发S3。
具体的信令流程图如图6所示,其具体的业务触发信令流程流程如下:
CC模块收到一条会话消息,并检查此消息,发现此消息并不属于任意某个会话实例,是一条会话初始请求消息,于是调用STE模块业务触发流程;
STE模块调用STPE模块执行策略逻辑模块,获取业务触发序列,即S1;
根据业务触发序列调用RE模块,检查业务S1是否满足业务触发规则,并返回匹配成功;
STE根据S1业务信息,修改会话请求消息,并返回给CC模块;
CC模块根据会话控制逻辑对此消息进行控制处理;
经过时间T1后,CC模块接收来自业务S1所在的AS返回的响应,再次调用STE模块进行业务触发;
STE模块调用STPE模块获取业务触发序列,STPE根据会话请求中的消息,返回业务序列S3;
STE根据返回的结果调用RE模块检查该会话是否满足触发业务S3的触发规则;
RE模块根据会话请求信息执行业务匹配,并返回匹配成功;
STE模块根据S3业务信息,修改会话请求消息,并返回给CC模块;
CC模块根据会话请求信息和会话控制逻辑,对此消息进行处理,并等待AS执行S3后返回的结果;
执行后续的流程;
动态的业务触发顺序:一般的业务触发顺序只由业务的优先级来决定,并且这个优先级是保存在用户的iFC中,这使得业务的触发顺序具有一定的静态性,不方便根据业务的执行状态实时调整业务的执行顺序,而SSTM可以根据一些辅助信息,如业务状态而实时地调整业务的触发顺序,提高业务触发的动态性;
灵活的复杂组合业务实现:基于状态的业务触发,可以实时地根据业务的实际运行情况,动态地调整业务的触发顺序,这正是实现组合业务的一个前提条件。例如实现呈现业务与补充业务的组合业务,用户当前的不同状态决定了调用不同的补充业务,SSTM正好满足这个需求;
便捷的服务间通信:提供各个服务的服务器在逻辑上都是独立的功能实体,它们之间没有固定的通信接口,故服务与服务之间如果需要交流信息的话,可以通过扩展的SIP消息进行通信,前提是服务在执行逻辑的同时,可以解析此SIP消息。
以上对本发明实施例所提供的,进行了详细介绍,本文中应用了具体个例对本发明的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本发明的方法及其核心思想;同时,对于本领域的一般技术人员,依据本发明的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本发明的限制。