CN101252704B

Movatterモバイル変換

Info

Publication number: CN101252704B
Application number: CN2008100873159A
Authority: CN
Inventors: 史以兵
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2008-03-18
Filing date: 2008-03-18
Publication date: 2011-11-02
Anticipated expiration: 2028-03-18
Also published as: MX2010010228A; EP2247124B1; WO2009115033A1; RU2010142385A; CN101252704A; EP2247124A1; BRPI0910929A8; BRPI0910929B1; RU2465741C2; EP2247124A4

Abstract

本发明公开了一种多媒体消息业务的实现方法，包括：多媒体消息业务中心接收消息提交请求；多媒体消息服务中心根据所述消息提交请求中携带的用户标识，在已存的消息定购信息中查找消息业务控制功能装置为用户定购的业务触发点；当到达所述业务触发点时，多媒体消息服务中心向所述消息业务控制功能装置发起业务处理请求；消息业务控制功能装置根据所述业务处理请求携带的用户标识，在已存的业务定购信息中查找所述用户定购的业务，并进行相应的业务处理。本发明相应的公开了实现本发明方法的相关设备及系统。采用本发明避免了多媒体消息业务中心将用户发送的每条消息都触发到消息业务控制功能装置，导致消息业务控制功能装置压力过大的问题。

Description

多媒体消息业务的实现方法、系统及相关设备

技术领域

本发明涉及通信技术领域，尤其涉及一种多媒体消息业务的实现方法、系统及相关设备。

背景技术

多媒体消息业务(Multimedia Messaging Service，MMS)是短消息业务(Short Message Service，SMS)和增强型消息业务(Enhanced Message Service，EMS)的进一步发展，为个人多媒体移动通信业务提供了完整的端到端解决方案。

从通信内容上讲，多媒体消息包括图像、音频、视频和数据等；从功能上讲，多媒体消息业务涵盖了终端到终端、终端到应用、应用到终端的多媒体消息通信。它不仅实现了终端之间、终端和应用之间的信息传递，还实现了内容的多样性，包括图片、语音、图像、数据和文本的各种组合。作为一个开放的媒体接入平台，MMS可以在移动用户和互联网内容提供商的互动下，衍生出更丰富多彩的内容业务应用。

在实际应用中，运营商除了使用多媒体消息业务中心(MultimediaMessaging Service Center，MMSC)完成多媒体消息的存储转发，一般还会在MMSC上部署一些增值业务。比如，运营商可以向用户提供签名档业务，当MMSC接收到用户提交的一条消息后，MMSC在消息内容末尾自动添加一个用户事先设置好的签名并下发给接收方；运营商还可以向用户提供主叫回执业务，当用户提交的消息下发完毕后，MMSC通过短消息等形式通知用户消息的发送结果。

在对现有技术的研究和实践过程中，发明人发现现有技术存在以下问题：

MMSC本身是一个要求具有高可靠性的电信网络设备，直接将增值业务放在MMSC中实现，一方面会增加MMSC的复杂性，导致MMSC的开发难度增加，影响增值业务的推出速度；另一方面又会使MMSC性能下降，从而使得运营商的总体运营成本(TCO)上升。

发明内容

本发明实施例要解决的技术问题是提供一种多媒体消息业务的实现方法、系统及相关设备，消除了直接在MMSC实现增值业务给MMSC带来的负担。

为解决上述技术问题，本发明所提供的实施例是通过以下技术方案实现的：

一种多媒体消息业务的实现方法，包括：

多媒体消息业务中心接收消息提交请求；

所述多媒体消息服务中心根据所述消息提交请求中携带的用户标识，在已存的消息定购信息中查找消息业务控制功能装置为所述用户定购的业务触发点；

当到达所述业务触发点时，所述多媒体消息服务中心向所述消息业务控制功能装置发起业务处理请求；

所述消息业务控制功能装置根据所述业务处理请求携带的用户标识，在已存的业务定购信息中查找所述用户定购的业务，并进行相应的业务处理。

一种消息业务控制功能装置，包括：

业务定购请求接收单元，用于接收携带业务定购信息的业务定购请求；

业务定购信息保存单元，用于保存所述业务定购信息，所述业务定购信息至少包括：用户标识和业务类型标识；

消息定购请求发送单元，用于当业务定购请求接收单元接收到业务定购请求时，向多媒体消息服务中心发送携带消息定购信息的消息定购请求，所述消息定购信息至少包括：用户标识和业务触发点；

业务处理请求接收单元，用于接收多媒体消息服务中心在到达业务触发点时发起的业务处理请求；

业务处理单元，用于根据所述业务处理请求携带的用户标识，在已存的业务定购信息中查找所述用户定购的业务，并进行相应的业务处理。

一种多媒体消息服务中心，包括：

消息提交请求接收单元，用于接收用户代理提交的消息提交请求；

业务触发点查找单元，用于根据消息提交请求中携带的用户标识，在已存的消息定购信息中查找消息业务控制功能装置为所述用户定购的业务触发点；

业务处理请求发送单元，用于当到达所述业务触发点时，向所述消息业务控制功能装置发起业务处理请求。

一种多媒体消息业务的实现系统，包括：多媒体消息服务中心，消息业务控制装置；

所述多媒体消息服务中心包括：

业务处理请求发送单元，用于当到达所述业务触发点时，向所述消息业务控制功能装置发起业务处理请求；

所述消息业务控制功能装置包括：业务处理请求接收单元，业务查找单元，业务处理单元；

业务处理请求接收单元，用于接收业务处理请求发送单元发起的业务处理请求；

业务查找单元，用于根据所述业务处理请求携带的用户标识，在已存的业务定购信息中查找所述用户定购的业务，并触发业务处理单元进行相应的业务处理。

上述技术方案具有如下有益效果：

以上为本发明实施例提供的多媒体消息业务的实现方法，由上述实现过程可知，本发明实施例通过MMSC和MSCF之间的消息交互，实现了多媒体消息业务的处理，消除了直接在MMSC中实现业务给MMSC带来的负担，并且，由于MMSC中保存了MSCF预先向其定购的消息信息，因此，MMSC只会将MSCF向其定购的消息发送给MSCF进行相应的业务处理，避免了MMSC将用户发送的每条消息都触发到MSCF，导致MSCF压力过大的问题。

附图说明

图1为本发明实施例提供的多媒体消息业务的实现方法流程图；

图2为本发明实施例提供的签名档业务的实现方法流程图；

图3为本发明实施例提供的主叫回执业务的实现方法流程图；

图4为本发明实施例提供的广告志愿者业务的实现方法流程图；

图5为本发明实施例提供的消息业务控制功能装置组成示意图；

图6为本发明实施例提供的多媒体消息业务的实现系统组成示意图。

具体实施方式

为使本发明实施例的目的、技术方案、及优点更加清楚明白，以下参照附图对本发明实施例进行详细说明。

3GPP规范24.140中定义了MM10接口，引入了消息业务控制功能装置(Messaging Service Control Function，MSCF)的概念，明确了MMSC和MSCF之间的交互流程。

本发明实施例对现有的MM10接口进行了扩展，请参见表1，为本发明实施例提供的扩展后的MM10接口所包括的消息，表中斜体字表示新扩展的消息：

消息	类型	方向
			MM10_Subscribe.REQ	请求	MSCF-＞MMSC
MM10_Subscribe.RES	响应	MMSC-＞MSCF
			MM10_Interrogation.REQ	请求	MMSC-＞MSCF
MM10_Interrogation.RES	响应	MSCF-＞MMSC

表1

其中，MM10_Subscribe.REQ消息由MSCF发起，用于向MMSC定购消息。MM10_Interrogation.REQ/.RES消息是对现有3GPP标准协议规定的MM10_Interogation.REQ/.RES消息扩展若干字段后得到的消息，MM10_Interrogation.REQ由MMSC发起，用于将用户提交的消息触发到MSCF进行相应的业务处理。

表1中各消息的具体定义请参见表2至表5(其中，斜体字表示新扩展的字段)：

信息装置	存在情况	说明
			Message Type	必备	消息类型，本消息取值为“MM10_Subscribe.REQ”。
Transaction ID	必备	事务ID，用于标识和MM10_Subscribe.RES的对应关系。
			Subscriber	必备	订购业务的用户号码。
Trigger Point	必备	MMSC向MSCF转发消息的业务触发点。对发送方用户设置4个触发点：·TPA1：MMSC收到提交消息且未发送响应，编码为0xF0·TPA2：MMSC收到提交消息且已发送响应，编码为0xF1·TPA3：MMSC已开始将通知消息发送给接收方，编码为0xF2·TPA4：MMSC已处理完用户提交的消息，编码为0xF3对发送方用户设置3个触发点：·TPB1：MMSC向接收方下发push通知前，编码为0xF4·TPB2：MMSC已成功向接收方下发push通知，编码为0xF5·TPB3：MMSC已完成消息下发流程，编码为0xF6
			Need Body	可选	MMSC向MSCF转发的消息中是否需要携带消息体。
Wait for Response	可选	MMSC在向MSCF转发消息后是否需要等待响应。

表2订购请求消息MM10_Subscribe.REQ定义

信息装置	存在情况	说明
			Message Type	必备	消息类型，本消息取值为“MM10_Subscribe.RES”。
Transaction ID	必备	事务ID，用于标识和MM10_Subscribe.REQ的对应关系。
			Status code	必备	指明订购是否成功。

表3订购响应消息MM10_Subscribe.RES定义

信息装置	存在情况	说明
			Message Type	必备	消息类型，本消息取值为“MM10_Interrogation.REQ”。
Transaction ID	必备	事务ID，用于标识和MM10_Interrogation.RES的对应关系。
			Trigger Event	必备	触发此消息的业务触发点。
Message ID	必备	MM的标识。
			Originator Message ID	可选	消息的原始ID。如果消息是从其他MMSC前转进来的，需要将消息在原MMSC的ID放在此字段中携带到MSCF。
Recipient(s)address	必备	消息接收方的地址：可能存在多个地址。
			Sender address	必备	消息发送方的地址
Sender Presentation	可选	呈现给发送方的发送方标识
			Content type	必备	消息内容的内容类型
Message class	可选	消息的类别(例如，个人业务、广告业务和信息业务).
			Date and time	必备	用户代理最近处理(即，提交或转发)MM的时间和日期
Time of Expiry	可选	消息的有效期
			Earliest delivery time	可选	最早下发时间
Delivery report	可选	递送报告的请求

Originator R/S delivery report	可选	MMSC递送报告请求。对于从其他MMSC前转来的消息，本字段表示发送方MMSC是否请求MM的递送报告。
			Priority	可选	消息的优先级
Sender visibility	可选	请求在将消息发送给接收方时，显示或隐藏发送方的标识
			Read reply	可选	阅读报告的请求
Subject	可选	消息标题
			Forward_counter	可选	表示消息被转发次数的计数器
Previously-sent-by	可选	在转发情况下，此信息装置包含一个或多个处理(即，转发或提交)过消息的MMS用户代理的地址，这些用户代理先于其地址包含在“发送方”地址信息装置中的MMS用户代理。应标明所提供地址的顺序。应标明始发方MMS用户代理的地址。
			Previously-sent-date- and-time	可选	在MMS用户代理上次处理(即，转发或提交)MM的日期和时间
Applic-ID	可选	目的应用的标识
			Reply-Applic-ID	可选	MM回复路径的标识
Aux-Applic-Info	可选	辅助应用地址信息
			Content Class	可选	MM的内容中包含的媒体类别
DRM Content	可选	指示MM的内容包含有数字水印保护信息
			Adaptations	可选	指示MM的内容是否可以进行内容适配(默认True)
Originator-Sysrem-Ad dress	可选	发送方MMSC的地址。对于从其他MMSC前转进来的消息，此字段必填。
			Send Status	可选	消息的下发状态，只在TPA4、TPB3点有效。
Content	可选	多媒体消息的内容

表4业务处理请求消息MM10_Interrogation.REQ定义

信息装置	存在情况	说明
			Message Type	必备	消息类型，本消息取值为“MM10_Interrogation.RES”。
Transaction ID	必备	事务ID，用于标识和MM10_Interrogation.REQ的对应关系。
			Process Status	必备	处理结果，包括：接受、拒绝、修改消息、正常结束、异常结束。
Message ID	必备	MM的标识。
			Recipient(s)address	必备	消息接收方的地址：可能存在多个地址。
Sender address	必备	消息发送方的地址
			Content type	必备	消息内容的内容类型
Message class	可选	消息的类别(例如，个人业务、广告业务和信息业务).
			Time of Expiry	可选	消息的有效期
Earliest deliverytime	可选	最早下发时间
			Delivery report	可选	递送报告的请求
Priority	可选	消息的优先级
			Sender visibility	可选	请求在将消息发送给接收方时，显示或隐藏发送方的标识
Read reply	可选	阅读报告的请求
			Subject	可选	消息标题
Forward_counter	可选	表示消息被转发次数的计数器
			Content Class	可选	MM的内容中包含的媒体类别
Content	可选	多媒体消息的内容

表5业务处理响应消息MM10_Interrogation.RES定义

以上对本发明实施例提供的MM10接口进行了详细介绍，在具体实现时技术人员可以按照需要重新定义表中所列各扩展字段的名称，上表中的名称仅为更清楚的说明本实施例，不应视为对本发明实施例的限制。

以下结合附图对本发明实施例提供的多媒体消息业务的实现方法进行介绍。

请参见图1，为本发明实施例提供的多媒体消息业务的实现方法，包括：

步骤101：用户代理提交携带业务定购信息的业务定购请求至MSCF；

其中，所述业务定购信息用于向MSCF指明定购业务用户的身份，定购业务的类型，因此，所述业务定购信息至少包括：用户标识，业务类型标识。

在具体实现时，定购业务的用户标识通常是用户的手机号码，并且，由于多媒体消息业务的种类繁多，包括诸如签名档业务、主叫回执业务以及广告志愿者业务等等，因此，业务类型标识用于标识该业务定购请求是用来定购哪一种业务。比如，可以预先定义业务类型标识为00，表示该定购请求是签名档业务定购请求；业务类型标识为01，表示该请求是主叫回执业务定购请求；业务类型标识为11，表示该请求是广告志愿者业务定购请求。

当定购请求是签名档业务定购请求时，上述业务定购信息进一步携带：用户设置的签名档。

步骤102：MSCF保存所述业务定购信息，并向MMSC发送携带的消息定购信息的消息定购请求(MM10_Subscribe.REQ)；

其中，消息定购信息至少包括：用户标识和业务触发点，用于向MMSC指明在MMSC接收到所述用户标识提交的消息后，应当向MSCF发起业务请求处理，并且指明MMSC应向MSCF发起业务请求处理的业务触发点；

步骤103：MMSC保存所述消息定购信息，并返回定购响应消息(MM10_Subscribe.REQ)至MSCF。

以上介绍了用户定购多媒体消息业务的实现过程，以下介绍实现用户定购的多媒体消息业务的过程，包括：

步骤104：发送方用户代理(Originator UA)提交消息提交请求(MM1_Submit.REQ)至MMSC；

步骤105：MMSC根据消息提交请求中携带的用户标识，在已存的消息定购信息中查找MSCF为所述用户定购的业务触发点，当到达所述业务触发点时，MMSC向MSCF发起业务处理请求(MM10_Interrogation.REQ)；

步骤106：MSCF根据所述业务处理请求携带的用户标识，在已存的业务定购信息中查找所述用户定购的业务，进行相应的业务处理，并返回业务处理响应消息(MM10_Interrogation.RES)至MMSC。

以上为本发明实施例提供的实现多媒体消息业务的方法，由上述实现过程可知，本发明实施例通过MMSC和MSCF之间的消息交互，实现了多媒体消息业务的处理，消除了直接在MMSC中进行业务处理给MMSC带来的负担，并且，MMSC只将MSCF定购的消息发送给MSCF进行相应的业务处理，避免了MMSC将用户发送的每条消息都触发到MSCF，导致MSCF压力过大的问题。

以下结合前文已述三种不同的多媒体消息业务，对本发明实施例提供的方法进行详细介绍。

一、签名档业务

所谓签名档业务是指：对于定购签名档业务的用户提交的每一条消息(多媒体消息或纯文本消息)，系统都会在消息内容(消息体)的末尾自动添加发送方预先设置的签名，并将添加签名的消息下发给接收方。

请参见图2，为本发明实施例提供的签名档业务的实现方法，包括：

步骤201：用户提交签名档业务定购请求至MSCF；

其中，业务定购信息包括：用户标识，业务类型标识，签名档。

步骤202：MSCF保存所述业务定购信息，并向MMSC发起携带消息定购信息的MM10_Subscribe.REQ请求；

其中，消息定购信息中的业务触发点可以是TPA1点，也可以是TPA2点，并且，消息定购信息中需要包括：消息体标识(Need Body)和等待响应标识(Wait for Response)，用于向MMSC指明在发起业务处理请求时需要携带MM1_Submit.REQ中的消息体，并等待MSCF响应；

在具体实现时，MM10_Subscribe.REQ消息中的Subscribe字段用于携带用户标识，Trigger Point字段用于携带业务触发点，Need Body字段和Wait forResponse字段用于向MMSC指明在发起业务处理请求时需要携带消息体，并等待MSCF响应。

步骤203：MMSC保存MM10_Subscribe.REQ中携带的消息定购信息，并返回MM10_Subscribe.RES消息至MSCF。

以上介绍了用户定购签名档业务的实现过程，以下介绍实现用户定购的签名档业务的过程，所述方法包括：

步骤204：发送方用户代理提交MM1_Submit.REQ消息至MMSC；

其中，MM1_Submit.REQ中携带了发送方标识，接收方标识以及消息体；

步骤205：MMSC根据MM1_Submit消息携带的发送方标识，在已存的消息定购信息中查找到MSCF为所述用户定购的业务触发点是TPA2点，，并且MMSC向发送方用户代理返回提交响应(MM1_Submit.RES)消息；

步骤206：MMSC到达TPA2点，MMSC向MSCF发送业务处理请求(MM10_Interrogation.REQ)，并等待MSCF的响应；

其中，MM10_Interrogation.REQ消息需要包含Sender address字段，ContentType字段和Content字段，Content字段用于携带消息体；

步骤207：MSCF收到MM10_Interrogation.REQ消息后，根据所述发送方标识，在已存的业务定购信息中查找到所述用户定购了签名档业务，则MSCF解析Content Type字段和Content字段，并在消息体中加上发送方预设的签名档，然后，返回业务处理响应(MM10_Interrogation.RES)消息至MMSC；

具体实现时，MSCF将添加签名档的消息体放在MM10_Interrogation.RES消息的Content字段中返回给MMSC，并且，通过MM10_Interrogation.RES消息的Process Status字段向MMSC指明MMSC需要修改消息。

对于MSCF而言执行完上述步骤即已实现签名档业务，但为了将添加签名档的消息发送给接收方用户，上述方法还可以进一步包括：

步骤208：MMSC根据Process Status字段的指示保存已添加签名档的消息体，并发送通知(MM1_Notification.REQ)消息至接收方用户代理；

步骤209：接收方用户代理回送通知响应(MM1_Notification.RES)消息；

步骤210：接收方用户代理发起消息获取(MM1_Retrieve.REQ)请求；

步骤211：MMSC回送消息获取响应(MM1_Retrieve.RES)消息至接收方用户代理，通过MM1_Retrieve.RES消息将添加签名档的消息体发送给接收方用户代理(Recipient UA)；

步骤212：Recipient UA发送获取成功确认(MM1_Acknowledge.REQ) 消息至MMSC。

进一步，如果发送方用户请求MMSC返回递送报告，则在MMSC在收到MM1_Acknowledge.REQ消息后，进一步包括：

步骤213：MMSC向发送方用户代理返回递送报告(MM1_DeliveryReport.REQ)；

步骤214：发送方用户代理返回递送报告响应(MM1_DeliveryReport.RES)消息至MMSC。

以上介绍了业务触发点为TPA2点时本发明实施例提供的签名档业务的一种实现过程。业务触发点为TPA2点时的第二种实现过程是在步骤205中MMSC可以先向发送方用户代理返回提交响应(MM1_Submit.RES)消息，然后，再查找MSCF为所述用户定购的业务触发点，并不影响本发明实施例的实现。如果业务触发点是TPA1点，实现过程与TPA2点基本相同，区别仅在于：MMSC在向发送方用户代理返回提交响应(MM1_Submit.RES)消息之前，向MSCF发起业务处理请求。

二、主叫回执业务

所谓主叫回执业务，是指对定购回执业务的发送方用户提交的每一条消息，系统都会以短消息的形式通知发送方消息的发送状态。

请参见图3，为本发明实施例提供的主叫回执业务实现方法，所述方法包括：

步骤301：用户提交向MSCF提交携带业务定购信息的主叫回执业务定购请求；

其中，业务定购信息包括：用户标识和业务类型标识；

步骤302：MSCF保存所述业务定购信息，并向MMSC发起携带消息定购信息的消息定购请求(MM10_Subscribe.REQ)，；

其中，消息定购信息中的业务触发点可以是：TPA3和TPA4业务触发点，或者，也可以是TPA3和TPA4业务触发点中的任意一个业务触发点，并且，发起业务处理请求时不需要携带消息体，且不需要等待MSCF响应；

在具体实现时，MM10_Subscribe.REQ消息的Subscribe字段用于携带用户标识，Trigger Point字段用于携带业务触发点。

步骤303：MMSC保存所述消息定购信息，并返回MM10_Subscribe.RES至MSCF。

以上介绍了用户定购主叫回执业务的实现过程，以下介绍实现用户定购的主叫回执业务的过程，所述方法包括：

步骤304：发送方用户代理提交MM1_Submit.REQ请求至MMSC；

步骤305：MMSC根据发送方标识，在已存的消息定购信息中查找到MSCF为所述用户定购的业务触发点是TPA3和TPA4点，并向发送方用户代理返回MM1_Submit.RES；

步骤306：MMSC发送MM1_Notification.REQ消息至接收方用户代理；

步骤307：接收方用户代理回送MM1_Notification.RES消息至MMSC；

步骤308：MMSC到达TPA3点，MMSC向MSCF发送业务处理请求(MM10_Interrogation.REQ)；

在具体实现时，MM10_Interrogation.REQ消息中的字段Sender address携带发送方标识；

步骤309：MSCF根据所述发送方标识，在已存的业务定购信息中查找到所述用户定购了主叫回执业务，则MSCF向发送方用户代理发送一条回执消息，提示发送方PUSH通知已发送完成；

步骤310：接收方用户代理发起消息获取请求(MM1_Retrieve.REQ)；

步骤311：MMSC回送消息获取响应(MM1_Retrieve.RES)；

其中，MM1_Retrieve.RES的消息内容字段中包括消息体，若发送方用户还定购了签名档业务，则MM1_Retrieve.RES携带添加签名档的消息体。

步骤312：接收方用户代理发送MM1_Acknowledge.REQ消息至MMSC；

步骤313：MMSC到达TPA4点，MMSC向MSCF发送业务处理请求(MM10_Interrogation.REQ)；

在具体实现时，MM10_Interrogation.REQ必须携带Sender address字段和Send Status字段；

步骤314：MSCF收到MM10_Interrogation.REQ消息后，从Sender address 字段获取发送方标识，并根据Send Status获取消息下发状态，然后向发送方用户代理发送一条回执消息，提示用户消息下发的最终结果。

进一步，如果发送方用户请求MMSC返回递送报告，则在MMSC向MSCF发送业务处理请求(MM10_Interrogation.REQ)消息后，进一步包括：

步骤315：MMSC向发送方用户代理返回递送报告(MM1_DeliveryReport.REQ)；

步骤316：发送方用户代理返回递送报告响应(MM1_DeliveryReport.RES)消息至MMSC。

以上为本发明实施例提供的主叫回执业务的一种实现方式，在本发明其他实施例中，步骤305可以在步骤306之后执行，也可以在步骤307和步骤308之间执行，并不影响本发明实施例的实现。

三、广告志愿者业务

所谓广告志愿者业务，是指某些用户自愿在自己接收到的消息中增加广告信息，以换取运营商的广告分成。

请参见图4，为本发明实施例提供的广告志愿者业务实现方法，包括：

步骤401：用户提交携带业务定购信息的广告志愿者业务定购请求至MSCF；

其中，所述业务定购信息包括：用户标识，业务类型标识；

步骤402：MSCF保存所述业务定购信息，并向MMSC发起携带消息定购信息的消息定购请求(MM10_Subscribe.REQ)；

其中，消息定购信息中的业务触发点是：TPB1点和TPB3点，并且，当定购TPB1点时，消息定购信息需要包括：消息体标识和等待响应标识，用于向MMSC指明发起业务处理请求时需要携带消息体并等待MSCF响应；定购TPB3点，MMSC发起业务处理请求时无需携带消息体，且无需等待MSCF响应；

步骤403：MMSC保存MM10_Subscribe.REQ消息中携带的消息定购信息，并返回定购响应消息(MM10_Subscribe.RES)至MSCF。

以上介绍了用户定购广告志愿者业务的实现过程，以下介绍实现用户定购的广告志愿者业务的过程，所述方法包括：

步骤404：发送方用户代理提交MM1_Submit.REQ请求至MMSC；

其中，MM1_Submit.REQ消息包括：发送方标识，接收方标识和消息体；

步骤405：MMSC根据接收方标识，在已存的消息定购信息中查找到MSCF为所述用户定购的业务触发点是TPB1和TPB3点，，并且MMSC向发送方用户代理返回MM1_Submit.RES消息；

步骤406：MMSC到达TPB1点，向MSCF发送MM10_Interrogation.REQ，并等待MSCF的响应；

在具体实现时，在MM10_Interrogation.REQ消息中需要包含Content Type和Content字段。

步骤407：MSCF收到MM10_Interrogation.REQ消息后，根据接收方标识，在已存的业务定购信息中查找到接收方用户定购了广告志愿者业务，则MSCF分析消息中的Content Type和Content等字段，并在Content字段携带的消息体后添加广告信息，并通过MM10_Interrogation.RES消息将添加广告信息的消息体返回至MMSC，并在Process Status字段中指明MMSC需要修改消息。

步骤408：MMSC按照MSCF的要求保存添加广告信息的消息体，并向接收方用户发送MM1_Notification.REQ消息；

步骤409：接收方用户代理回送MM1_Notification.RES消息；

步骤410：接收方用户代理发起MM1_Retrieve.REQ请求；

步骤411：MMSC回送MM1_Retrieve.RES消息，其中，MM1_Retrieve.RES的消息内容中携带添加广告信息的消息体。

步骤412：接收方用户代理发送MM1_Acknowledge.REQ至MMSC；

步骤413：MMSC到达TPB4点，向MSCF发起MM10_Interrogation.REQ消息，其中，MM10_Interrogation.REQ消息中包含Send Status字段，以指明消息下发结果；MSCF收到MM10_Interrogation.REQ消息后，根据Send Status字段显示的下发状态决定是否给用户以广告补偿。

进一步，如果发送方用户请求MMSC返回递送报告，则在MMSC向MSCF 发送业务处理请求(MM10_Interrogation.REQ)消息后，进一步包括：

步骤414：MMSC向发送方用户代理发送MM1_DeliveryReport.REQ；

步骤415：发送方用户代理返回递送报告响应(MM1_DeliveryReport.RES)消息至MMSC。

以上介绍了本发明实施例提供的方法，技术人员可以根据本发明实施例提供的方法在一个MSCF中同时实现上述三种多媒体消息业务，也可以在三个MSCF中实现上述三种多媒体消息业务，并不影响本发明实施例的实现。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括如下步骤：

一种多媒体消息业务的实现方法，包括：多媒体消息业务中心接收消息提交请求；所述多媒体消息服务中心根据所述消息提交请求中携带的用户标识，在已存的消息定购信息中查找消息业务控制功能装置为所述用户定购的业务触发点；当到达所述业务触发点时，所述多媒体消息服务中心向所述消息业务控制功能装置发起业务处理请求；所述消息业务控制功能装置根据所述业务处理请求携带的用户标识，在已存的业务定购信息中查找所述用户定购的业务，并进行相应的业务处理。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。

本发明实施例还提供了一种消息业务控制功能装置，请参见图5，包括：

业务定购请求接收单元501，用于接收携带业务定购信息的业务定购请求；

业务定购信息保存单元502，用于保存所述业务定购信息，所述业务定购信息至少包括：用户标识和业务类型标识；

消息定购请求发送单元503，用于当业务定购请求接收单元接收到业务定购请求时，向多媒体消息服务中心发送携带消息定购信息的消息定购请求，所述消息定购信息至少包括：用户标识和业务触发点；

为了完成用户发起的业务处理，消息业务控制功能装置还包括：

业务处理请求接收单元504，用于接收业务处理请求；

业务查找单元505，用于根据所述业务处理请求携带的用户标识，在业务定购信息保存单元502查找所述用户定购的业务；

业务处理单元506，用于根据业务查找单元505查找到的业务，进行相应的业务处理。

本发明实施例提供的消息业务控制功能装置实现了向MMSC定购消息，使得MMSC只将MSCF定购的消息发送给MSCF进行相应的业务处理，避免了MMSC将用户发送的每条消息都触发到MSCF，导致MSCF压力过大的问题

本发明实施例还提供了一种多媒体消息业务的实现系统，请参见图6，包括：多媒体消息服务中心601，消息业务控制装置602；

多媒体消息服务中心601包括：

消息提交请求接收单元6011，用于接收用户代理提交的消息提交请求；

业务触发点查找单元6012，用于根据消息提交请求中携带的用户标识，在已存的消息定购信息中查找消息业务控制功能装置为所述用户定购的业务触发点；

业务处理请求发送单元6013，用于当到达所述业务触发点时，向所述消息业务控制功能装置发起业务处理请求；

消息业务控制功能装置602包括：

业务处理请求接收单元6021，用于接收业务请求发送单元发起的业务处理请求；

业务查找单元6022，用于根据所述业务处理请求携带的用户标识，在已存的业务定购信息中查找所述用户定购的业务；

业务处理单元6023，用于根据业务查找单元查找到的业务，进行相应的业务处理。

在上述消息业务控制功能装置中，还可以进一步包括：

在上述多媒体消息服务中心中还可以进一步包括：

消息定购请求接收单元，用于接收所述消息定购请求发送单元发起的消息定购请求；

消息定购信息保存单元，用于保存所述消息定购请求中携带的消息定购信息。

以下针对上述三种不同的多媒体消息业务介绍本发明实施例提供的系统。

一、签名档业务

用户代理提交的业务定购请求是签名档业务定购请求，则业务定购信息保存单元保存的业务定购信息进一步包括：签名档；

消息定购请求发送单元发送的消息定购信息进一步包括：消息体标识和等待响应标识；

消息定购请求发送单元发送的业务触发点具体为：TPA1点或TPA2点。

并且，所述业务处理请求发送单元6013发送的业务处理请求进一步携带消息提交请求中的消息体和发送方标识；

业务处理单元6023是签名档业务处理单元，用于当到达TPA1点或TPA2点时，根据发送方标识，在已存的业务定购信息中查找发送方预设的签名档，将所述签名档添加到所述消息体中，通过业务处理响应消息将添加签名档的消息体返回至所述多媒体消息服务中心。

二、主叫回执业务

用户提交的业务定购请求是主叫回执业务请求，则所述消息定购请求发送单元发送的业务触发点为TPA3点和/或TPA4点；

以及，当到达的业务触发点是TPA3点时，所述业务处理请求发送单元6013发送的业务处理请求携带发送方标识；

所述业务处理单元6023包括：第一主叫回执业务处理单元，用于：向发送方用户代理发送一条回执消息，提示发送方用户系统已经向接收方用户发送了通知消息。

当所述业务触发点是TPA4点时，所述业务处理请求发送单元6013发送的业务处理请求携带发送方标识和消息下发状态标识；

所述业务处理单元6023进一步包括：第二主叫回执业务处理单元；

第二主叫回执业务处理单元用于：

根据消息下发状态标识指示的消息下发状态，向发送方用户代理发送一条回执消息，提示用户消息下发的最终结果。

三、广告志愿者业务

用户代理提交的业务定购请求是广告志愿者业务定购请求，则所述消息定购请求发送单元发送的业务触发点是TPB1点和TPB3点；

并且，当到达的业务触发点是TPB1点时，所述消息定购请求发送单元发送的消息定购信息进一步包括：消息体标识和等待响应标识。

以及，当到达的业务触发点是TPB1点时，所述业务处理请求发送单元6013发送的业务处理请求携带接收方标识；

所述业务处理单元6023包括：广告志愿者业务处理单元：

根据所述接收方标识，已存的业务定购信息中查找接收方预订的广告信息，将所述广告信息添加到消息体中，并通过业务处理响应消息将添加广告信息的消息体返回至多媒体消息服务中心。

当到达的业务触发点是TPB3点时，所述业务处理请求发送单元6013发送的业务处理请求携带接收方标识和消息下发状态标识；

所述业务处理单元6023进一步包括：计费补偿单元；

计费补偿单元，用于根据消息下发状态标识显示的消息下发状态决定是否给用户以广告补偿。

以上对本发明所提供的一种多媒体消息业务的实现方法、系统及相关设备进行了详细介绍，对于本领域的一般技术人员，依据本发明实施例的思想，在具体实施方式及应用范围上均会有改变之处，综上所述，本说明书内容不应理解为对本发明的限制。