WO2009115033A1

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

Info

Publication number: WO2009115033A1
Application number: PCT/CN2009/070836
Authority: WO
Inventors: 史以兵
Original assignee: 华为技术有限公司
Priority date: 2008-03-18
Filing date: 2009-03-17
Publication date: 2009-09-24
Also published as: EP2247124A4; MX2010010228A; RU2465741C2; EP2247124B1; CN101252704A; BRPI0910929A8; CN101252704B; RU2010142385A; EP2247124A1; BRPI0910929B1

Description

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

本申请要求于 2008 年 3 月 18 日提交中国专利局、申请号为 200810087315.9、发明名称为 "多媒体消息业务的实现方法、系统及相关设备" 的中国专利申请的优先权，其全部内容通过引用结合在本申请中。

技术领域

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

背景技术

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

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

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

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

发明内容

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

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

本发明实施例提供了一种多媒体消息业务的实现方法，包括：

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

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

当到达所述业务触发点时，所述多媒体消息服务中心向所述消息业务控制功能装置发起业务处理请求，所述业务处理请求包括所述用户标识，以便于所述消息业务控制功能装置根据所述业务处理请求携带的用户标识，在已存的业务订购信息中查找所述用户订购的业务，并进行相应的业务处理。

本发明实施例还提供了一种多媒体消息业务的实现方法，包括：

接收多媒体消息服务中心发起的业务处理请求，所述业务处理请求包括用户标识；

才艮据所述用户标识在已存的业务订购信息中查找所述用户订购的业务，并进行相应的业务处理。

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

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

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

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

本发明实施例还提供了一种多媒体消息服务中心，包括：

消息提交请求接收单元，用于接收用户代理提交的消息提交请求；业务触发点查找单元，用于根据消息提交请求中携带的用户标识，在已存的消息定购信息中查找消息业务控制功能装置为所述用户定购的业务触发点；业务处理请求发送单元，用于当到达所述业务触发点时，向所述消息业务控制功能装置发起业务处理请求。

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

所述多媒体消息服务中心用于接收用户代理提交的消息提交请求；根据消息提交请求中携带的用户标识，在已存的消息订购信息中查找消息业务控制功能装置为所述用户订购的业务触发点；当到达所述业务触发点时，向所述消息业务控制功能装置发起业务处理请求；

所述消息业务控制功能装置接收业务请求发送单元发起的业务处理请；根据所述业务处理请求携带的用户标识，在已存的业务订购信息中查找所述用户订购的业务；根据所述业务查找单元查找到的业务，进行相应的业务处理。

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

以上为本发明实施例提供的多媒体消息业务的实现方法，由上述实现过程可知，本发明实施例通过 MMSC和消息业务控制功能装置（Messaging Service Control Function, MSCF )之间的消息交互，实现了多媒体消息业务的处理，消除了直接在 MMSC中实现业务给 MMSC带来的负担。

附图说明

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

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

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

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

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

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

具体实施方式

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

第三代合作伙伴计划（3GPP )规范 24.140中定义了 MM10接口，引入了消息业务控制功能装置（ Messaging Service Control Function, MSCF )的概念，明确了 MMSC和 MSCF之间的交互流程。

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

表 1

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

表 1中各消息的具体定义请参见表 2至表 5 (其中，斜体字表示新扩展的字段)：信息装置存在情况说明

消息类型必备消息类型，本消息取值为" MM10_Subscribe.REQ"。

( Message Type ) 事物标识必备事务 ID , 用于标识和 MM10_Subscribe.RES的对应

( Transaction ID ) 关系。

订购用户必备订购业务的用户号码。

( Subscriber )

业务触发点必备 MMSC向 MSCF转发消息的业务触发点。

( Trigger Point ) 对发送方用户设置 4个触发点：

• 发送方业务触发点 1 ( TPA1 ): MMSC收到提交消息且未发送响应，编码为 OxFO

• 发送方业务触发点 2 ( TPA2 ): MMSC收到提交消息且已发送响应，编码为 OxFl

• 发送方业务触发点 3 ( TPA3 ): MMSC已开始将通知消息发送给接收方，编码为 0xF2 • 发送方业务触发点 4 ( TPA4 ): MMSC已处理完用户提交的消息，编码为 0xF3

对接收方用户设置 3个触发点：

• 接收方业务触发点 1 ( TPB1 ): MMSC向接收方下发推送（push )通知前，编码为 0xF4 • 接收方业务触发点 2 ( TPB2 ): MMSC已成功向接收方下发推送（push )通知，编码为 0xF5 • 接收方业务触发点 3 ( TPB3 ): MMSC已完成消息下发流程，编码为 0xF6

消息体标识（Need 可选 MMSC向 MSCF转发的消息中是否需要携带消息 Body ) 体。

等待响应标识（Wait 可选 MMSC在向 MSCF转发消息后是否需要等待响应。 for Response )

表 2 订购请求消息 MM10— Subscribe.REQ定义信息装置存在情况说明

消息类型必备消息类型，本消息取值为

( Message Type ) "MM10_Subscribe.RES" o

事物标识必备事务 ID, 用于标识和 MM10_Subscribe.REQ的 ( Transaction ID ) 对应关系。

状态码必备指明订购是否成功。

( Status code )

表 3 订购响应消息 MM10— Subscribe.RES定义信息装置存在情况说明

消息类型（Message 必备消息类型，本消息取值为

Type ) "MM1 O Interrogation.REQ"。

事物标识必备事务 ID , 用于标识和 MM10 Interrogation.RES ( Transaction ID ) 的对应关系。

触发事件（Trigger 必备触发此消息的业务触发点。

Event )

消息标识 ( Message 必备多媒体消息 (MM) 的标识。

ID )

消息的原始标识可选消息的原始标识。如果消息是从其他 MMSC前 ( Originator Message 转进来的, 需要将消息在原 MMSC的标识放在 ID ) 此字段中携带到 MSCF。

接收方地址必备消息接收方的地址：可能存在多个地址。 ( Recipient(s)

address )

发送方地址 ( Sender 必备消息发送方的地址

address )

发送方呈现标识可选呈现给接收方的发送方标识

( Sender

Presentation ) 内容类型 ( Content 必备消息内容的内容类型.

type )

消息类另 J¹ (Message 可选消息的类别 (例如, 个人业务、广告业务和信 class ) 息业务）.

曰期和时间 (Date 必备用户代理最近处理 (即, 提交或转发） MM 的 and time ) 时间和日期.

消息的有效期 (Time 可选消息的有效期

of Expiry )

最早下发时间可选最早下发时间

( Earliest delivery

time )

递送报告 ( Delivery 可选递送^ =艮告的请求

report )

发送方彩信中心是否可选 MMSC递送 4艮告请求。对于从其他 MMSC前转来需要递送报告的消息, 本字段表示发送方 MMSC是否请求 MM ( Originator R/S 的递送报告。

delivery report )

优先级 (Priority ) 可选消息的优先级

发送方是否隐藏标识可选请求在将消息发送给接收方时，显示或隐藏发 ( Sender visibility ) 送方的标 i只

阅读报告的请求可选阅读报告的请求

( Read reply )

标题 (Subject ) 可选消息标题

转发计数器可选表示消息被转发次数的计数器.

( Forward counter )

始发方地址可选在转发情况下, 此信息装置包含一个或多个处 ( Previously-sent-by ) 理 (即, 转发或提交)过消息的 MMS用户代理的地址, 这些用户代理先于其地址包含在"发送方"地址信息装置中的 MMS用户代理。应标明所提供地址的顺序。应标明始发方 MMS用户代理的地址。

始发时间可选在 MMS用户代理上次处理 (即, 转发或提交)

( Previously-sent-dat MM的日期和时间

e-and-time )

目的应用的标识可选目的应用的标识

(Applic-ID )

回复路径的标识可选 MM回复路径的标识

( Reply-Applic-ID )

辅助应用地址信息可选辅助应用地址信息

( Aux-Applic-Info )

内容类另 J¹ ( Content 可选 MM的内容中包含的媒体类另j i

Class )

内容包含水印 (DEM 可选指示 MM的内容包含有数字氷印保护信息

Content )

适酉己 ( Adaptations ) 可选指示 MM的内容是否可以进行内容适酉 ί (默认

True )

发送方系统地址可选发送方 MMSC的地址。对于从其他 MMSC前转进 ( Originator-System- 来的消息, 此字段必填。

Address )

下发状态 (Send 可选消息的下发状态, 只在 ΤΡΛ4、 ΤΡΒ3点有效。

Status )

内容 ( Content ) 可选多媒体消息的内容

表 4 业务处理请求消息 MM10— Interrogation.REQ定义信息装置存在情说明

况

消息类型必备消息类型，本消息取值为

( Message Type ) "MM10_Interrogation.RES"。

事物标识必备事务 ID , 用于标识和业务处理请求 ( Transaction ID ) (MM10 Interrogation.REQ ) 的对应关系。

处理结果 (Process 必备处理结果, 包括: 接受、拒绝、修改消息、正常结 Status ) » 常结

消息标识必备 MM的标识。

(Message ID )

接收方地址必备消息接收方的地址：可能存在多个地址。

( Recipient(s)

address )

发送方地址必备消息发送方的地址

( Sender address )

内容类型必备消息内容的内容类型.

( Content type )

消息类别可选消息的类别 (例如, 个人业务、广告业务和信息业

( Message class ) 务）.

消息的有效期可选消息的有效期

( Time of Expiry )

最早下发时间可选最早下发时间

( Earliest delivery

time )

递送报告可选递送报告的请求

( Delivery report )

优先级 (Priority ) 可选消息的优先级

发送方是否隐藏可选请求在将消息发送给接收方时, 显 '隐藏发送方 ( Sender 的标识

visibility )

阅读报告的请求可选阅读报告的请求

( Read reply )

标题 (Subject ) 可选消息标题

转发计数器可选表示消息被转发次数的计数器. ( Forward counte

r )

内容类别（Content 可选 MM的内容中包含的媒体类另j i

Class )

内容 ( 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 保存所述消息订购信息，并返回消息订购响应消息 ( MMlO Subscribe.REQ )至 MSCF。

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

步骤 104 : 发送方用户代理（ Originator UA ) 提交消息提交请求

( MMl Submit.REQ )至 MMSC;

步骤 105: MMSC根据消息提交请求中携带的用户标识，在已存的消息订购信息中查找 MSCF 为所述用户订购的业务触发点，当到达所述业务触发点时， MMSC向 MSCF发送业务处理请求（ MM10— Interrogation.REQ );

步骤 106: MSCF根据所述业务处理请求携带的用户标识，在已存的业务订购信息中查找所述用户订购的业务，进行相应的业务处理，并返回业务处理响应消息（MMlO 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 for Response字段用于向 MMSC指明在发送业务处理请求时需要携带消息体，并等待 MSCF响应。

步骤 203: MMSC保存消息订购请求（MM10— Subscribe.REQ ) 中携带的消息订购信息，并返回消息订购响应（MM10— Subscribe.RES )消息至 MSCF。

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

步骤 204: 发送方用户代理提交消息提交请求（ MM1— Submit.REQ ) 消息至 MMSC;

其中，消息提交请求（ MM1— Submit.REQ )中携带了发送方标识，接收方标识以及消息体；

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

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

其中，业务处理请求（ MMlO Interrogation.REQ ) 消息可以包含 Sender address字段， Content Type字段和 Content字段， Content字段用于携带消息体；步骤 207: MSCF收到业务处理请求（ MM10— Interrogation.REQ )消息后 , 根据所述发送方标识，在已存的业务订购信息中查找到所述用户订购了签名档业务，则 MSCF解析 Content Type字段和 Content字段，并在消息体中加上发送方预设的签名档，然后，返回业务处理响应（MM10— Interrogation.RES ) 消息至 MMSC; 具体实现时， MSCF 将添加签名档的消息体放在业务处理响应 ( MM10— Interrogation.RES )消息的内容字段中返回给 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 ) 发送获取成功确认 ( MMl Acknowledge.REQ ) 消息至 MMSC。

进一步，如果发送方用户请求 MMSC返回递送报告，则在 MMSC在收到获取成功确认 ( MMl Acknowledge.REQ ) 消息后，进一步包括：

步骤 213: MMSC向发送方用户代理返回递送 ^艮告请求

( MMl 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 保存所述消息订购信息，并返回消息订购响应

( MMlO 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发送业务处理请求 ( MM1 O Interrogation.REQ ); 在具体实现时，业务处理请求（ MM10— Interrogation.REQ )消息中的字段 Sender address携带发送方标识；

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

步骤 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发送业务处理请求 ( MM1 O Interrogation.REQ );

在具体实现时，业务处理请求（ MM1 O Interrogation.REQ )可以携带 Sender address字段和 Send Status字段；

步骤 314: MSCF收到业务处理请求（MM10— Interrogation.REQ )消息后，从 Sender address字段获取发送方标识，并根据 Send Status获取消息下发状态，然后向发送方用户代理发送一条回执消息，提示用户消息下发的最终结果。

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

步骤 315: MMSC向发送方用户代理返回递送告请求

( MMl 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 发送业务处理请求 ( MM1 O 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的要求保存添加广告信息的消息体，并向接收方用户发送通知（ MMl_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 发送业务处理请求 ( MM1 O Interrogation.REQ ) 消息，其中，业务处理请求 ( MM10— Interrogation.REQ )消息中包含 Send Status字段，以指明消息下发结果； MSCF收到业务处理请求（ MM10— Interrogation.REQ )消息后 ,根据 Send Status字段显示的下发状态决定是否给用户以广告补偿。

步骤 414: MMSC向发送方用户代理发送递送告请求

( MMl 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进一步包括：计费补偿单元；

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

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

Claims

权利要求

1、一种多媒体消息业务的实现方法，其特征在于，包括：

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

2、如权利要求 1所述的方法，其特征在于，所述方法进一步包括：接收所述消息业务控制功能装置发送的消息订购请求；

所述多媒体消息服务中心保存所述消息订购请求中携带的消息订购信息，所述消息订购信息包括：用户标识和业务触发点。

3、如权利要求 1或 2所述的方法，其特征在于，所述消息订购信息进一步包括：消息体标识和等待响应标识；

当到达所述业务触发点时 ,所述多媒体消息服务中心还将消息体携带在所述业务处理请求中发送给所述消息业务控制功能装置，并接收所述消息业务控制功能装置返回的修改后的消息体，将所述修改后的消息体发送给接收方。

4、如权利要求 3所述的方法，其特征在于，所述业务触发点具体为：多媒体消息服务中心收到消息提交请求且未发送响应或多媒体消息服务中心收到消息提交请求且已发送响应。

5、如权利要求 3或 4所述的方法，其特征在于，若所述用户订购的业务是签名档业务，则所述修改后的消息体为添加签名档的消息体；

若所述用户订购的业务是广告志愿者业务，则所述修改后的消息体为添加广告信息的消息体。

6、如权利要求 1或 2所述的方法，其特征在于，若到达的业务触发点是多媒体消息服务中心已处理完用户提交的消息，则所述多媒体消息服务中心消息还将下发状态标识携带在向所述消息业务控制功能装置发起的业务处理请求中。

7、一种多媒体消息业务的实现方法，其特征在于，包括：

8、如权利要求 7所述的方法，其特征在于，还包括：

接收用户代理提交的业务定购请求，并保存所述业务定购请求携带的业务定购信息，所述业务定购信息包括：用户标识和业务类型标识；

向多媒体消息服务中心发送携带消息订购信息的消息定购请求，所述消息订购信息包括用户标识和业务触发点，以便所述多媒体消息服务中心接收到所述用户标识提交的消息后，在所述业务触发点发起业务处理请求。

9、如权利要求 8所述的方法，其特征在于，若用户代理提交的业务订购请求是签名档业务请求或广告志愿者业务定购请求，则所述消息定购信息进一步包括：消息体标识和等待响应标识，用于向所述多媒体消息服务中心指明在发起业务处理请求时需要携带所述消息提交请求中的消息体，并等待消息业务控制功能装置的响应。

10、如权利要求 7所述的方法，其特征在于，若所述用户订购的业务是签名档业务或广告志愿者业务，所述进行相应的业务处理具体包括：

从所述业务处理请求中获取消息体，将广告信息或用户预设的签名档添加到消息体中，并通过业务处理响应消息将所述添加广告信息或签名档的消息体返回所述多媒体消息服务中心。

11、如权利要求 7所述的方法，其特征在于，若所述用户订购的业务是主叫回执业务，所述进行相应的业务处理具体包括：向发送方用户代理发送一条回执消息，提示用户系统已将通知消息发送给接收方用户，或从所述业务处理请求中获取消息下发状态，向发送方用户代理发送一条回执消息，提示用户消息下发的最终结果。

12、一种消息业务控制功能装置，其特征在于，包括：

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

13、如权利要求 12所述的装置，其特征在于，所述装置还包括：业务定购请求接收单元，用于接收携带业务定购信息的业务定购请求；业务定购信息保存单元，用于保存所述业务定购信息，所述业务定购信息至少包括：用户标识和业务类型标识；

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

14、一种多媒体消息服务中心，其特征在于，包括：

15、如权利要求 14所述的多媒体消息服务中心，其特征在于，包括：消息定购请求接收单元，用于接收消息业务控制功能装置发起的消息定购请求；

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

16、一种多媒体消息业务的实现系统，其特征在于，包括：多媒体消息服务中心，消息业务控制装置；