CN109286904A - Ims系统、消息处理方法、装置和存储介质 - Google Patents

Abstract

本申请涉及一种IMS系统，包括短彩信中心和呼叫会话控制网元。短彩信中心通过ISC接口连接呼叫会话控制网元。短彩信中心用于通过MMS接口连接主叫用户端或被叫用户端。呼叫会话控制网元用于通过Gm接口连接主叫用户端或被叫用户端。短彩信中心接收到主叫用户端发送的上行消息后，若短彩信中心已存储被叫用户端的注册信息，则发起消息下发流程，通过呼叫会话控制网元向被叫用户端下发彩信消息或短消息。其中，上行消息包括彩信消息或短消息。通过短彩信中心统一管理短消息和彩信消息的接收及发送处理，省去原短信中心和彩信中心两个网元之间的通信接口，大大降低了系统复杂度，也提高了数据处理和传输效率、减少通信资源开销以及提高内存利用率。

Description

IMS系统、消息处理方法、装置和存储介质

技术领域

本申请涉及通信技术领域，特别是涉及一种IMS系统、消息处理方法、装置和存储介质。

背景技术

随着通信技术的发展，出现了IP多媒体子系统(也即IMS系统)。IMS(IPMultimedia Subsystem)系统是第三代移动通信组织3GPP在Release5版本标准中提出的支持IP多媒体业务的子系统。IMS系统基于SIP的体系，SIP是按客户端/服务器方式工作的基于文本的信令协议，各种类型的客户端通过IMS系统都可以建立起端到端的IP通信，并获得所需要的服务质量。IMS系统提供会晤管理、注册、安全、计费、承载控制和漫游等完成服务所提供必须的功能。可以说IMS系统提供了业务融合的基础，基于IP技术可同时支持话音、数据和多媒体业务以及其他新应用。

IMS系统中，短信业务作为一项基本的电信业务，主要通过信令通道传输有限长度的文本消息。彩信业务则是与短信业务不同，彩信业务可以传送文本、图片、音频和视频等内容，传输长度远超短消息业务160个字节的限制。在传统的IMS系统中，短信业务所对应的短信中心，以及彩信业务所对应的彩信中心属于不同的AS(Application System，应用系统)网元，也即是说短信业务和彩信业务分别在不同的AS网元上进行接收、处理以及发送。然而，在实现本发明的过程中，发明人发现传统的IMS系统中至少存在着系统复杂度高的问题。

发明内容

基于此，有必要针对上述技术问题，提供一种能够大幅降低系统复杂度的IMS系统、一种消息处理方法、一种消息处理装置和一种存储介质。

为实现上述目的，本发明实施例采用以下技术方案：

一方面，本发明实施例提供一种IMS系统，包括：

短彩信中心和呼叫会话控制网元，所述短彩信中心通过ISC接口连接所述呼叫会话控制网元；

所述短彩信中心用于通过MMS接口连接主叫用户端或被叫用户端，所述呼叫会话控制网元用于通过Gm接口连接所述主叫用户端或所述被叫用户端；

所述短彩信中心接收到所述主叫用户端发送的上行消息后，若所述短彩信中心已存储被叫用户端的注册信息，则发起消息下发流程，通过所述呼叫会话控制网元向所述被叫用户端下发彩信消息或短消息；其中，所述上行消息包括所述彩信消息或短消息。

在其中一个实施例中，还包括归属签约用户服务器，所述归属签约用户服务器分别通信连接所述呼叫会话控制网元和所述短彩信中心，所述归属签约用户服务器用于向所述短彩信中心提供所述被叫用户端的业务数据。

另一方面，还提供一种消息处理方法，包括：

接收主叫用户端发送的上行消息；其中，所述上行消息包括短消息或彩信消息；

若已存储所述上行消息对应的被叫用户端的注册信息，则发起消息下发流程，将所述上行消息下发至所述被叫用户端。

在其中一个实施例中，所述方法还包括：

若未存储所述上行消息对应的所述被叫用户端的所述注册信息，则获取所述被叫用户端的业务数据；其中，所述业务数据为IMS系统的归属签约用户服务器上存储的业务数据；

若根据所述业务数据确定所述被叫用户端为外网用户端，则转发所述上行消息至所述IMS系统连接的外网。

在其中一个实施例中，所述方法还包括：

若根据所述业务数据确定所述被叫用户端为所述IMS系统的用户端，且所述被叫用户端为直属用户端，则缓存所述上行消息。

在其中一个实施例中，所述若根据所述业务数据确定所述被叫用户端为所述IMS系统的用户端，且所述被叫用户端为直属用户端，则缓存所述上行消息的步骤后，还包括：

若接收到所述被叫用户端的所述注册信息，则重新组建所述上行消息并发起消息下发流程，将所述上行消息下发至所述被叫用户端。

在其中一个实施例中，所述方法还包括：

若根据所述业务数据确定所述被叫用户端为所述IMS系统的用户端，且所述被叫用户端为外属用户端，则转发所述上行消息至所述被叫用户端归属的短彩信中心。

在其中一个实施例中，所述方法还包括：

若接收到所述上行消息对应的下发失败消息，则缓存所述上行消息。

另一方面，还提供一种消息处理装置，包括：

收发模块，用于接收主叫用户端发送的上行消息，以及将所述上行消息下发至所述被叫用户端；其中，所述上行消息包括短消息或彩信消息；

控制模块，用于发起消息下发流程；

数据容器模块，用于存储所述上行消息对应的被叫用户端的注册信息。

再一方面，还提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现所述的消息处理方法的步骤：

上述技术方案中的一个技术方案具有如下优点和有益效果：

上述IMS系统、消息处理方法、装置和存储介质，通过将短信中心和彩信中心两个独立的网元融合为一个网元，也即短彩信中心，由短彩信中心统一管理短消息和彩信消息的接收及发送处理。在短彩信中心内，省去原短信中心和彩信中心两个网元之间的通信接口，用户鉴权信息不再需要分别拷贝、备份到两个不同的网元中，从而减少核心网对外部AS网元的管理对接，大大降低了系统复杂度，也提高了数据处理和传输效率、减少通信资源开销以及提高内存利用率。

附图说明

图1为一个实施例中IMS系统的网元结构框图；

图2为一个实施例中消息处理方法的第一流程示意图；

图3为一个实施例中消息处理方法的第二流程示意图；

图4为一个实施例中消息处理方法的第三流程示意图；

图5为一个实施例中消息处理方法的第四流程示意图；

图6为一个实施例中消息处理的路由选择示意图；

图7为一个实施例中消息处理装置的结构框图；

图8为一个实施例中短彩信中心的协议层示意图；

图9为一个实施例中短彩信中心的功能模块示意图。

具体实施方式

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

请参阅图1，在一个实施例中，提供一种IMS系统100，包括短彩信中心12和呼叫会话控制网元14。短彩信中心12通过ISC接口连接呼叫会话控制网元14。短彩信中心12用于通过MMS_M接口(也即3GPP32240协议中的MMS Relay/Server和MMS Client之间的接口，也称MM1接口)连接主叫用户端或被叫用户端。呼叫会话控制网元14用于通过Gm接口连接主叫用户端或被叫用户端。短彩信中心12接收到主叫用户端发送的上行消息后，若短彩信中心12已存储被叫用户端的注册信息，则发起消息下发流程，通过呼叫会话控制网元14向被叫用户端下发彩信消息或短消息。其中，上行消息包括彩信消息或短消息。

可以理解，上述的主叫用户端可以是上述IMS系统的主叫用户端，也可以是与上述IMS系统所在核心网通信的外网20主叫用户端。进一步的，上述IMS系统的主叫用户端，可以是归属于上述短彩信中心12的直属主叫用户端，也可以是归属于上述IMS系统中的其他短彩信中心12的外属主叫用户端。上述的被叫用户端的归属可以同理理解。短彩信中心12可以根据被叫用户端的注册信息来判断被叫用户端的归属地。需要说明的是，图1中示出的是UE 30可以是主叫用户端，也可以是被叫用户端。

具体的，短彩信中心12在接收到直属主叫用户端、外属主叫用户端或者外网20上其他主叫用户端发送的上行消息后，将会查询自身内部是否已经存储有被叫用户端的注册信息。若短彩信中心12确认已存储有被叫用户端的注册信息，也即是说，被叫用户端归属于该短彩信中心12且处于在线可接收前述上行消息的状态。短彩信中心12则会按照协议发起消息下发流程。消息下发流程可以是通过呼叫会话控制网元14向被叫用户端下发短消息，也可以是通过呼叫会话控制网元14向被叫用户端下发彩信消息，如向被叫用户端下发彩信PUSH消息。

被叫用户端在接收到的下行消息为彩信消息时，可以直接通过MMS接口，从短彩信中心12上下载对应的彩信内容至本地。被叫用户端在接收到的下行消息为彩信消息时，也可以在接收到所属用户(即机主)输入的彩信接收指令后，通过MMS接口从短彩信中心12上下载对应的彩信内容至本地。可以理解，若短彩信中心12确认未存储有被叫用户端的注册信息，也即是说，被叫用户端处于离线状态、为外属被叫用户端或者为外网20被叫用户端时，短彩信中心12将对应执行缓存上行消息、转发上行消息至被叫用户端归属的其他短彩信中心12或者转发上行消息至外网20等流程。其中，短彩信中心12将上行消息缓存后，例如缓存到IMS系统的数据库的相应位置，可以待被叫用户端(也即归属于该短彩信中心12的直属被叫用户端)上线时，例如短彩信中心12接收到被叫用户端接入IMS系统进行注册时提交的注册信息，则可以将缓存的上行消息重新组建以发起下发流程，将上行消息下发到被叫用户终端。

需要说明的是，本领域技术人员可以理解，上述的注册信息为本领域中IMS系统在进行短信或彩信服务过程中所需的用户鉴权数据。上述的被叫用户端接收到下发的短消息或者彩信消息后，IMS系统内各网元还可以完成基于本领域现行的相关协议的其他流程，例如短彩信中心12通过Ro接口(也即3GPP32240协议中的Ro接口)与计费系统(OCS)40连接实现的计费处理等其他流程。上述的各接口均为本领域IMS系统中的相应网元所使用的常规接口。

上述IMS系统，通过将短信中心和彩信中心两个独立的网元融合为一个网元，也即短彩信中心12，由短彩信中心12统一管理短消息和彩信消息的接收及发送处理。在短彩信中心12内，省去原短信中心和彩信中心两个网元之间的通信接口，用户鉴权信息不再需要分别拷贝、备份到两个不同的网元中，从而减少核心网对外部AS网元的管理对接，大大降低了系统复杂度，也提高了数据处理和传输效率、减少通信资源开销以及提高内存利用率。

如图1所示，在一个实施例中，上述的IMS系统还包括归属签约用户服务器16。归属签约用户服务器16分别通信连接呼叫会话控制网元14和短彩信中心12。归属签约用户服务器16用于向短彩信中心12提供被叫用户端的业务数据。

其中，归属签约用户服务器16(Home Subscriber Server，HSS)为本领域中IMS系统内常规的HSS服务器。业务数据为归属签约用户服务器16上保存的被叫用户端的用户信息，用于对被叫用户端进行本领域常规的用户鉴权等。归属签约用户服务器16与呼叫会话控制网元14之间的通信连接为本领域常规的Cx接口连接。归属签约用户服务器16与短彩信中心12之间的通信连接为本领域常规的Sh接口连接。本领域技术人员可以理解，上述的呼叫会话控制网元14具体包括I-CSCF网元、S-CSCF网元和P-CSCF网元。P-CSCF网元通过本领域常规的Mw接口与I-CSCF网元、S-CSCF网元连接。

具体的，若短彩信中心12确认未存储有被叫用户端的注册信息时，短彩信中心12通过Sh接口向归属签约用户服务器16查询被叫用户端的业务数据，以确定被叫用户端的鉴权结果，例如通过被叫用户端的业务数据确定被叫用户端的业务能力和归属地址等。短彩信中心12通过Sh接口与归属签约用户服务器16进行交互，即可以确定待下发的上行消息所需下发至的被叫用户端或者是否可以直接下发至被叫用户端等情况，例如被叫用户端是否具备彩信业务能力。通过上述的归属签约用户服务器16与短彩信中心12、呼叫会话控制网元14之间的交互可以，有效确保主叫用户端发送上行消息后，快速完成被叫用户端的鉴权、主叫或被叫用户端的注册流程等。

请参阅图2，在一个实施例中，还提供了一种消息处理方法，以该方法应用于图1中的IMS系统为例进行说明，包括以下步骤S12和S14：

S12，接收主叫用户端发送的上行消息；其中，上行消息包括短消息或彩信消息。

具体地，短彩信中心12可以通过呼叫会话控制网元14接收IMS系统中的主叫用户端发送的上行消息，也可以接收外网20的主叫用户端发送的上行消息。上行消息可以是短消息，也即承载短信业务的待处理消息，也可以是彩信消息，也即承载彩信业务的待处理消息。

S14，若已存储上行消息对应的被叫用户端的注册信息，则发起消息下发流程，将上行消息下发至被叫用户端。

具体的，短彩信中心12接收到上行消息后，将会查询自身内部是否已经存储有被叫用户端的注册信息。例如查询自身内部的用户信息容器(UserMgr)中是否已有被叫用户端的注册信息。若短彩信中心12确认已存储有被叫用户端的注册信息，也即是说，被叫用户端归属于该短彩信中心12且处于在线可接收前述上行消息的状态。短彩信中心12则会按照协议发起消息下发流程。消息下发流程可以是通过呼叫会话控制网元14向被叫用户端下发短消息，也可以是通过呼叫会话控制网元14向被叫用户端下发彩信消息，如向被叫用户端下发彩信PUSH消息，以使被叫用户端接收到彩信PUSH消息后，到短彩信中心12下载主叫用户端发送的彩信内容。

上述消息处理方法中，通过短彩信中心12统一管理短消息和彩信消息的接收及发送处理。在短彩信中心12内，省去原短信中心和彩信中心两个网元之间的通信接口，用户鉴权信息不再需要分别拷贝、备份到两个不同的网元中，从而减少核心网对外部AS网元的管理对接，大大降低了系统复杂度，也提高了数据处理和传输效率、减少通信资源开销以及提高内存利用率。

在一个实施例中，上述的消息处理方法中，还包括如下步骤：若接收到上行消息对应的下发失败消息，则缓存上行消息。

可以理解，短彩信中心12在向被叫用户端下发上行消息时，若被叫用户端无法正常接收到上行消息，例如通信链路中断、被叫用户端掉线或者其他干扰导致消息接收失败等情况下，短彩信中心12将会收到下行链路反馈的消息下发失败的响应消息。此时，短彩信中心12对未能下发成功的上行消息进行缓存，例如通过短彩信中心12内部的短彩信消息容器(SmsMsMgr)，将上行消息缓存至IMS系统的数据库中，以待被叫用户端上线后，从数据库中读取上下文对应的内存内容，并重新生成上行消息及相应的上下文，将上行消息下发至被叫用户端。

上述的步骤，避免了短彩信中心12接收到上行消息时，即进行上行消息的缓存而占用数据库内存资源。通过在短彩信中心12收到上行消息下发失败的响应后，再进行上行消息的缓存，从而可以有效节省数据库资源。

请参阅图3，在一个实施例中，上述的消息处理方法，还包括步骤S16和S18：

S16，若未存储上行消息对应的被叫用户端的注册信息，则获取被叫用户端的业务数据；其中，业务数据为IMS系统的归属签约用户服务器16上存储的业务数据。

具体的，短彩信中心12查询自身内部的用户信息容器时，若在未查询到存储的被叫用户端的注册信息，则需要向归属签约用户服务器16查询被叫用户端的业务数据，以确定被叫用户端是处于离线状态、还是外属被叫用户端或者是外网20被叫用户端。

S18，若根据业务数据确定被叫用户端为外网20用户端，则转发上行消息至IMS系统连接的外网20。

具体的，短彩信中心12根据被叫用户端的业务数据确定被叫用户端属于外网20用户端时，例如短彩信中心12根据业务数据进行鉴权，确定被叫用户端不是短彩信中心12所在的IMS系统用户，不具备彩信接收能力等时，短彩信中心12将可以根据被叫用户端的业务数据确定的归属信息，转发上行消息至外网20。例如被叫用户端归属的短信中心或彩信中心所在的核心网，也即IMS系统连接的外网20，以便外网20将上行消息转发至被叫用户端。短彩信中心12通过上述的步骤S16和S18，直接向归属签约用户服务器16查询被叫用户端的业务数据进行统一的鉴权，确定被叫用户端的归属和业务能力等信息，从而实现上行消息的高效转发。

请参阅图4，在一个实施例中，上述的消息处理方法，还包括步骤S20：

S20，若根据业务数据确定被叫用户端为IMS系统的用户端，且被叫用户端为直属用户端，则缓存上行消息。

具体的，短彩信中心12在根据被叫用户端的业务数据确定被叫用户端属于IMS系统的用户，并且归属于自身，也即被叫用户端为短彩信中心12的直属用户端时，确定被叫用户端当前为无法接收上行消息的状态，例如关机或不在服务区等离线状态。短彩信中心12则将待下发的上行消息进行缓存，例如缓存短信或者彩信消息的实体，在短信消息或者彩信消息的生命周期内，管理数据库中短信内容或者彩信内容的存储等。

通过上述步骤S20，短彩信中心12在被叫用户端为注册在线时，直接在上行消息的生命周期内，进行待下发的上行消息的可靠缓存，避免上行消息丢失，缓存处理流程简便，有效提升消息缓存效率。

在一个实施例中，如图4所示，上述的消息处理方法中，步骤S20之后还包括步骤S22：

S22，若接收到被叫用户端的注册信息，则重新组建上行消息并发起消息下发流程，将上行消息下发至被叫用户端。

具体的，归属于短彩信中心12的被叫用户端接入网，例如重新返回IMS系统服务区或者重新上线时，被叫用户端的注册信息将会注册到短彩信中心12，例如短彩信中心12通过归属签约用户服务器16获得被叫用户端的注册信息。短彩信中心12将读取缓存至数据库中的短信消息内容或者彩信消息内容，并重新生成短消息或者彩信消息的实体的上下文，从而发起消息下发流程，将上线消息下发至被叫用户端。通过上述的步骤S22，可以确保被叫用户端上线后，短彩信中心12向被叫用户端下发上行消息的效率，

请参阅图5和图6，在一个实施例中，上述的消息处理方法，还包括步骤S17：

S17，若根据业务数据确定被叫用户端为IMS系统的用户端，且被叫用户端为外属用户端，则转发上行消息至被叫用户端归属的短彩信中心12。

具体的，如图5和图6所示，在上述的消息处理方法，短彩信中心12在根据被叫用户端的业务数据确定被叫用户端为上述IMS系统的用户端，并且被叫用户端为归属于上述IMS系统的其他短彩信中心12，也即被叫用户端为外属用户端时，短彩信中心12则将上行消息转发至被叫用户端所归属的其他短彩信中心12，以使被叫用户端所归属的其他短彩信中心12对主叫用户端发送的上行消息，通过发起消息下发流程，下发至被叫用户端。

通过上述的步骤S17，短彩信中心12在IMS系统内统一直接进行系统内的消息转发，交互简化，有效提高系统内消息转发效率。

应该理解的是，虽然图2-6的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，这些步骤可以以其它的顺序执行。而且，图2-6中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，这些子步骤或者阶段的执行顺序也不必然是依次进行，而是可以与其它步骤或者其它步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

请参阅图7，在一个实施例中，提供了一种消息处理装置200，包括收发模块12、控制模块14和数据容器模块16，其中：

收发模块12，用于接收主叫用户端发送的上行消息，以及将上行消息下发至被叫用户端；其中，上行消息包括短消息或彩信消息。

控制模块14，用于发起消息下发流程。

数据容器模块16，用于存储上行消息对应的被叫用户端的注册信息。

上述消息处理装置200中，通过各模块统一管理短消息和彩信消息的接收及发送处理，用户鉴权信息不再需要分别拷贝、备份到两个不同的网元中，从而减少核心网对外部AS网元的管理对接，大大降低了系统复杂度，也提高了数据处理和传输效率、减少通信资源开销以及提高内存利用率。

在一个实施例中，上述的消息处理装置200还包括业务查询模块和第一转发模块。业务查询模块用于在未存储上行消息对应的被叫用户端的注册信息时，获取被叫用户端的业务数据。其中，业务数据为IMS系统的归属签约用户服务器16上存储的业务数据。第一转发模块用于在根据业务数据确定被叫用户端为外网20用户端时，转发上行消息至IMS系统连接的外网20。

在一个实施例中，上述的消息处理装置200还包括第一缓存处理模块，用于在根据业务数据确定被叫用户端为IMS系统的用户端，且被叫用户端为直属用户端时，缓存上行消息。

在一个实施例中，上述的消息处理装置200还包括重建下发模块，用于在接收到被叫用户端的注册信息时，重新组建上行消息并发起消息下发流程，将上行消息下发至被叫用户端。

在一个实施例中，上述的消息处理装置200还包括第二转发模块，用于在根据业务数据确定被叫用户端为IMS系统的用户端，且被叫用户端为外属用户端时，转发上行消息至被叫用户端归属的短彩信中心12。

在一个实施例中，上述的消息处理装置200还包括第二缓存处理模块，用于在接收到上行消息对应的下发失败消息时，缓存上行消息。

关于消息处理装置200的具体限定可以参见上文中对于消息处理方法的限定，在此不再赘述。上述消息处理装置200中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

请参阅图8和图9，在一个实施例中，如图8所示，上述各实施例中的短彩信中心12均可以基于SIP协议封装。例如，短消息和彩信消息推送下层的功能均由SIP协议作底层协议封装。其中SIP头中可以封装用户号码类型(如SIPURI)、转发投递路由、AS中心号码和支持方式等信息。SIP BODY(SIP主体部分)可以包括短消息对应的短信内容或者彩信消息对应的彩信内容。其他协议层为本领域常规协议层。如图9所示，在短彩信中心12中，上述的各项业务功能可以分别由短信中心内的各功能模块来具体实现，例如，短彩信中心12整体可以划分为收发模块12也即通信层(Communication Layer)、控制模块14也即业务控制(Application Control)和数据容器模块16也即数据容器(Data Container)等三大部分。其中：

通信层负责各接口消息的接收和发送，其中：

SIP消息收发模块(SipProcessor)用于短彩信中心12通过ISC接口完成与S-CSCF网元的SIP消息收发，提供ISC接口上的SIP消息接收事件和发送服务。

Map消息收发模块(MapProcessor)用于完成与IMS系统连接的外网20Map消息的接收和发送服务，维护逻辑信令连接和传输信令数据单。

HTTP消息收发模块(HttpProcessor)用于完成与具备彩信接收能力的用户端的彩信内容接收和发送，提供MMS_M接口上的HTTP消息接收事件和发送服务。

SMTP消息收发模块(SmtpProcessor)用于完成IMS系统的外网20SMTP消息的接收和发送服务。

计费收发模块(DiameterProcessor)用于完成与计费系统OCS的Ro接口，以及与HSS客户信息的Diameter链路建立，提供数据通信信道(DCC)消息的接收和发送服务。

编解码模块(CodeLayer)用于对短信消息和彩信消息进行编解码，提取消息中的具体信息以及存储短彩信的结构体之间进行适配转换。

业务控制用于负责短信和彩信业务逻辑，其中：

业务逻辑控制模块(Processor)用于实现短信和彩信的流程控制，维护短彩信上行(也即MO)或者下行(也即MT)流程、存储管理、重发控制以及网内和互通业务的路由选择等。

数据容器用于负责存储业务和上下文管理，其中：

配置数据管理容器(ConfigMgr)用于与数据库交互、读取配置信息、监控和处理数据通信网(DCN)发出的信息变更事件。

短彩信消息容器(SmsMsMgr)用于缓存短信或者彩信消息实体，在短信或者彩信生命周期内管理数据库中短信或者彩信的存储和删除，业务进程启动时读取数据库中的相应信息重新生成短信或者彩信消息实体的上下文。

用户信息容器(UserMgr)用于短彩信用户端进行第三方注册或者去注册时维护用户端的注册数据，在短彩信处理流程中提供主叫或者被叫用户端的注册信息查询。

消息队列模块(MsgQueue)用于管理短信或者彩信重发队列，以及定时发送队列，通过定时器产生时间触发Processor的消息下发流程。

在一个实施例中，提供了一种计算机可读存储介质，其上存储有计算机程序，计算机程序被处理器执行时实现以下步骤：接收主叫用户端发送的上行消息；其中，上行消息包括短消息或彩信消息；若已存储上行消息对应的被叫用户端的注册信息，则发起消息下发流程，将上行消息下发至被叫用户端。

在一个实施例中，计算机程序被处理器执行时还可以实现上述各实施例中消息处理方法的各增加步骤。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，所述的计算机程序可存储于一非易失性计算机可读取存储介质中，该计算机程序在执行时，可包括如上述各方法的实施例的流程。其中，本申请所提供的各实施例中所使用的对存储器、存储、数据库或其它介质的任何引用，均可包括非易失性和/或易失性存储器。非易失性存储器可包括只读存储器(ROM)、可编程ROM(PROM)、电可编程ROM(EPROM)、电可擦除可编程ROM(EEPROM)或闪存。易失性存储器可包括随机存取存储器(RAM)或者外部高速缓冲存储器。作为说明而非局限，RAM以多种形式可得，诸如静态RAM(SRAM)、动态RAM(DRAM)、同步DRAM(SDRAM)、双数据率SDRAM(DDRSDRAM)、增强型SDRAM(ESDRAM)、同步链路(Synchlink)DRAM(SLDRAM)、存储器总线(Rambus)直接RAM(RDRAM)、直接存储器总线动态RAM(DRDRAM)、以及存储器总线动态RAM(RDRAM)等。

以上实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。因此，本申请专利的保护范围应以所附权利要求为准。

Claims (10)

1.一种IMS系统，其特征在于，包括短彩信中心和呼叫会话控制网元，所述短彩信中心通过ISC接口连接所述呼叫会话控制网元；

所述短彩信中心用于通过MMS接口连接主叫用户端或被叫用户端，所述呼叫会话控制网元用于通过Gm接口连接所述主叫用户端或所述被叫用户端；

所述短彩信中心接收到所述主叫用户端发送的上行消息后，若所述短彩信中心已存储被叫用户端的注册信息，则发起消息下发流程，通过所述呼叫会话控制网元向所述被叫用户端下发彩信消息或短消息；其中，所述上行消息包括所述彩信消息或短消息。

2.根据权利要求1所述的IMS系统，其特征在于，还包括归属签约用户服务器，所述归属签约用户服务器分别通信连接所述呼叫会话控制网元和所述短彩信中心，所述归属签约用户服务器用于向所述短彩信中心提供所述被叫用户端的业务数据。

3.一种消息处理方法，应用于权利要求1或2所述的IMS系统，其特征在于，包括：

接收主叫用户端发送的上行消息；其中，所述上行消息包括短消息或彩信消息；

若已存储所述上行消息对应的被叫用户端的注册信息，则发起消息下发流程，将所述上行消息下发至所述被叫用户端。

4.根据权利要求3所述的消息处理方法，其特征在于，所述方法还包括：

若未存储所述上行消息对应的所述被叫用户端的所述注册信息，则获取所述被叫用户端的业务数据；其中，所述业务数据为IMS系统的归属签约用户服务器上存储的业务数据；

若根据所述业务数据确定所述被叫用户端为外网用户端，则转发所述上行消息至所述IMS系统连接的外网。

5.根据权利要求4所述的消息处理方法，其特征在于，所述方法还包括：

若根据所述业务数据确定所述被叫用户端为所述IMS系统的用户端，且所述被叫用户端为直属用户端，则缓存所述上行消息。

6.根据权利要求5所述的消息处理方法，其特征在于，所述若根据所述业务数据确定所述被叫用户端为所述IMS系统的用户端，且所述被叫用户端为直属用户端，则缓存所述上行消息的步骤后，还包括：

若接收到所述被叫用户端的所述注册信息，则重新组建所述上行消息并发起消息下发流程，将所述上行消息下发至所述被叫用户端。

7.根据权利要求4至6任一项所述的消息处理方法，其特征在于，所述方法还包括：

若根据所述业务数据确定所述被叫用户端为所述IMS系统的用户端，且所述被叫用户端为外属用户端，则转发所述上行消息至所述被叫用户端归属的短彩信中心。

8.根据权利要求3所述的消息处理方法，其特征在于，所述方法还包括：

若接收到所述上行消息对应的下发失败消息，则缓存所述上行消息。

9.一种消息处理装置，其特征在于，包括：

收发模块，用于接收主叫用户端发送的上行消息，以及将所述上行消息下发至所述被叫用户端；其中，所述上行消息包括短消息或彩信消息；

控制模块，用于发起消息下发流程；

数据容器模块，用于存储所述上行消息对应的被叫用户端的注册信息。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求3至8中任一项所述的消息处理方法的步骤。