一种融合消息系统的制作方法

专利名称：一种融合消息系统的制作方法
技术领域：
本发明涉及通信领域，尤其涉及消息业务中的融合消息系统。
技术背景随着电信业务的发展，出现了越来越多的消息业务。例如短消息业务(SMS， Short Message Service)，多媒体消息业务，即时消息(IM)业务，在实际应 用中典型的IM又有移动IM,基于Internet的IM等等，此外还有同时支持语音和 多媒体消息的即按即说的集群业务POC,以及日常使用频繁的Email。可见， 消息类业务已经成为当前电信和因特网业务的重要业务之一。而且可以预见， 消息类业务也是未来NGN/NGMN中的关键业务之一。常用的消息业务介绍如下(一)、短消息业务短消息业务采用存贮转发方式，其承栽通道为控制信令通道，故信息容量 不大， 一条短消息最多包含140个字节(160个字符或70个汉字)。运营商除了 提供短信用户间的^t/发短信业务，也和CP、 SP合作，利用短信的承栽通道开 展了信息点播、信息订阅等信息(内容)服务，开创了移动数据增值业务。SMS 信息容量小，信息表现形式单一。在GSM网(G网)引入GPRS分组承载通道 后，SMS可以分流到GPRS承载通道上，加大了SMS的信息容量，降低了信令 信道的负荷。如图1所示，是短消息系统在GSM网络中的位置示意图，其中短消息中心 (SMC， Short Message Center)是独立于GSM网络的一个业务处理系统，主要 功能是提交、存储、转发短消息，并完成与PSTN、 ISDN、 PSPDN等网络的互 通，以实现来自其他的SME的短消息的传递。 短消息系统在网络中的位置如图l所示，与短消息系统相关的物理实体为移动交换中心(MSC, Mobile Switch Center) /拜访位置寄存器(VLR Visitor Location Register)和归属位置寄存器(HLR， Home Location Register)，其各 自在短消息发送流程中的作用如下MSC:移动用户(MS, Mobile Subscriber)提交的短消息，通过基站子系 统(BSS, Base Station Subsystem)到达MSC后，MSC负责转交给对应的短消 息系统。对于短消息系统下发的短消息，MSC系统收到后，向VLR和HLR查询相关 路由、用户信息，通过BSS基站子系统向用户下发。VLR:提供用户发送短消息前的鉴权管理和下发短消息时MSC查找用户路由。HLR:短消息系统下发短消息前，查找用户归属MSC和MSC下发短消息时查找用户基本信息使用。 短消息业务的特点(1) SMS的传送采用存储转发方式，即短消息被发送出去后，不是直接 发送给接收方，而是先存储在短消息业务中心(SMSC, Short Message Service Center)，然后再由SMSC转发给接收方。MS无论在归属局还是在漫游时，均 可4t/发短消息；即使MS关机、不在无线覆盖范围内或SIM卡存储器中短信溢 出时，短消息中心的数据库自动存储发往该MS的短消息(一般不超过三天)， 在MS有效时，再发送出去；(2) 支持双向信息的传递，即利用移动台可收/发短消息；(3) 在发送短消息过程中，SMS发送方可以在发出短消息后收到一条确 认通知，返回传递成功或失败的消息，以及不可到达对方的原因。(二)多媒体消息业务多媒体消息业务(MMS, Multimedia Messaging Service)作为SMS的演进， 是独立于移动通信网络的一个业务处理系统，可适用于通用分组无线业务 (GRPS, General Packet Radio Service) 、 CDMA IX ( Code Division Multiple Access)、宽带码分多址(WCDMA， Wideband CDMA)等2.5G/3G网络，主 要完成多媒体消息的提交、存储和转发等功能。多媒体消息可以包括文本、图 形、动画、视频、音频等多种格式的内容。MMS业务可以有点到点、点到应 用、应用到点等使用方式。如图2所示，是MMS系统的标准架构示意图，MMS系统中的网络设备包括 MMS中继器(MMS Relay) 、 MMS服务器(MMS Server)、用户数据库(User Database)和用户代理(MMS User Agent)等。MMS服务器负责存储和处理到来和离开两个方向上的多媒体短消息。 每个MMSE中可以有多个MMS服务器，MMS服务器可以和外部网络的E-Mail 服务器、SMS服务器等通过标准的接口协同工作，为用户提供丰富的服务类型。MMS中继器负责在不同的消息系统之间传递消息，以整合处于不同网 络中的各种类型的服务器。MMS中继器在接收或者传递消息到其他的MMS用 户代理或者另外的MMSE时，应该能够产生计费数据(CDR)。 MMS中继器和 MMS服务器还具有地址翻译功能和临时存储多媒体短信的功能，以保证多媒 体短信在成功地传送到另 一个MMSE实体之前不会丢失。MMS用户数据库记录和用户相关的业务信息。如用户的业务特性、对 用户接入MMS服务的控制等。中。用户代理是一个应用层的功能实体，为用户提供浏览、合成和处理多媒体 短信的功能。对多々某体短信的处理包括发送、接收和删除等操作。MMS用户 代理还提供用户终端接收多媒体短信能力的协商；向用户发送多媒体短信通 知；对用户的多々某体短信加密和解密；用户之间的多^f某体短信签名；在用户的 SIM卡支持MMS的情况下，处理SIM卡中和MMS相关的信息；用户特性的管理等功化月匕。MMS的工作原理与流程: 多媒体信息服务建立在以WAP为载体数据传输网上。它可在GSM网络 (R7/R8) 、 GPRS网络、CDMA 1X和未来的3G网络中。但是为了获得用户满 意的带宽，最好是在GPRS、 CDMA1X或是3G网络环境下，当然也可用于在实 行了 HSCSD技术的GSM网络中。WAP技术在多媒体信息服务中扮演了重要角色。通过WAP的Push、 Notification和Poll的功能，终端用户能完成与系统的通信。以系统向手机发送信息为例，分析一下多媒体信息服务的流程，过程如下(1) 当有一条多々某体信息发往一个用户时，信息以WAP WSP的协议进行 编码，通过无线网络传送到WAP网关；(2) WAP网关以HTTP协议与MMS-Relay进行通信,将文件内容传送给 固S-Relay;(3) MMS-Relay将文件送往MMS-C服务器。在服务器内多媒体信息的 内容将转换成MIME的格式，并存储在短信存储器(MMS-Message Store )中；(4) 服务器进行数据分析，从而得到路由信息，用户终端信息等。在分 析过程中会调用用户数据库中信息。系统将判断用户的终端是否能够支持 MMS，并根据用户的终端的承载能力(如显示分辨率，终端的容量等)进行 不同的处理。例如当用户终端不支持MMS时，系统将把多媒体信息中的多媒 体信息去掉，只把信息的文字部分以短信的方式发给用户；(5) 确认处理方法之后，系统通过被叫用户的MSISDN号码进行路由。 MMS-Relay将通过WAP网关与外部网络进行通信。在没有确认被叫用户已经接 受了信息之前，该信息始终保存在短信存储器中。运营商可以通过软件"i殳定保 存的时间长度；(6) 系统服务器生成计费信息，传送给计费中心。 (三)即时消息即时消息的概念在固定网络和移动网络是类似的。OMA制定的移动IM与 其它的创新特性相融合，具有良好互联互通能力，增强用户的使用体验。用户
可以使用发送点到点消息和点到多点消息、将IM消息发送给不在线的终端，将 IM消息发送给非IM终端或未知终端，与E-mail互通、与其他IM系统(MSN、 ICQ等)互通等业务。 一般IM都附带有呈现(Presence)能力，presence是IM的 关键使能技术，它包含客户端设备有效性(手机开机/关闭，正在打电话)，用 户状态(有空、没空，正在开会)，位置，客户端设备能力(语音、文本、GPRS、 多媒体)和用于搜索的用户状态，比如说心情(高兴、生气)和爱好(足球、 钓鱼、计算机、跳舞)等。因为Presence属性是个人的，所以用户可以根据自 己的意愿进行权限控制。如图3所示，是OMA定义的基于SIPLE协议的IM系统架构，图中提供IMJ5良 务的最核心的是IM Client和IM Server两个实体IM客户端(IM Client)位于移动终端内，用于发^/参与/终止IM会话，以 及从对等的IM Clients或者IMServer发送和接收即时消息；IMI良务器(IM Server)位于网络侧，负责接收用户的IM^"请求，创建 和管理IM会活，JJ^JM消息，维护聊天室信息，负责4某体复制和分发；提供 在线传送和存储离线消息；提供移动IM与固网IM的交互，提供与远程IM系统 的互操作等。 (四)PoC:PoC业务的概念来自于对讲机，其用户体验使用方式和对讲机类似-简单、 快捷，半双工通话。用户通过预先设定通话群组，通话时无需拨号，按住特定 的按键，就可以同时将话音传送给群组中其他所有的成员，按键即讲，呼叫和 通话连接过程在瞬间完成。接收方无需任何响应就能接听，通话过程采用半双 工的方式， 一方在说话时，其他成员只能接听不能说话。制定PoC标准规范的组织是OMA (Open Mobile Alliance),该规范中定义 的PoC网络示意图如图4所示。PoC网络基于IMS (图中的"SIP/IPcore")，其 主要实体简介如下PoC服务器(PoC Server):是业务的主要呼叫控制设备，是IMS网络的一
种Application Server;PoC XDMS:存储PoC业务需要的群组信息等数据的服务器；PoC客户端(PoC Client):用户使用该客户端和PoC Server发起、接收PoC 呼叫、申请发言权、发言等。建立PoC群组呼叫(Group Talk)后，用户可以通过TBCP协议向PoC Server 申请发言权(Floor)，只有获得发言权，用户才被准许说话，其说话产生的媒 体流(TalkBurst)才能被PoCServer转发到群组的其他成员。如图5所示，是 一个发言权申请流程图，流程简介如下步骤501 - 502:用户可以通过TBCP协议"Talk Burst Request"消息向PoC Server申请发言权(Floor);步骤503 - 504: PoC Server返回"Talk Burst Granted"消息给申请者以告知他 已被准许发言；步骤505-506: PoC Server也向其他用户发出"Talk Burst Taken"消息，以 知会当前发言者信息给参与群组会话的其他成员；步骤507 - 510:获得发言的用户说话，其媒体流(Talk Burst) #PoC Server 转发给群组中的其他成员；步骤511-512:用户发言完毕，释放发言权；步骤513 - 516:群组发言权空闲，PoC Server向群组成员广播"Floor Control Idle"消息。考虑到消息业务的重要性，如何持续改进消息业务的体睑，简化消息业务 的实现，同时保护运营商的现有投资，正在成为业界的一个研究热点。目前， 各个标准组织已经纷纷建立相应的工作组和课题对这些消息类业务以及它们 的演*展进行标准化。此外，随着移动固定网络的全IP化，以及3GPPIMS子系统的发展，各类网 络业务和应用的IP化也是大势所趋，在全IP的条件下，采用统一的机制和方法 实现消息业务成为可能。
当前消息业务的一个特点是消息业务的种类很多，用户可以才艮据自己的需 要选择。也正是种类多，造成了用户在选择时无所适从，业务的使用体验比较差，例如发一个简单的文本消息时，使用SMS,发送图片的时候，使用MMS， 希望采用会话的方式实时沟通的时候，又使用IM业务，如果要进行半双工的语 音聊天又要切换到PoC,以及与此类似情况使得用户使用消息业务比较复杂。 此外，这些不同的消息业务有各自的实现系统和接口规范，维护成本、互通成 本都很高。总结一下现有消息的缺点，可以描述为用户需要在多种消息业务之间进行选择和切换，使用复杂，用户使用体验 可以进一步提高；消息业务功能类似，业务特性相互重叠；各个消息业务有各自的实现方式，分别基于不同的平台和架构，维护成本 高，互通困难；后续增加新的消息特性非常复杂，同时新的消息业务引入又容易造成用户 使用上的困惑；发明内容本发明提供一种融合消息系统，以简化用户使用，提高用户业务体验。为此本发明釆用如下方案一种融合消息系统，包括第一用户设备，安装有第一客户端程序，用于发起消息业务请求； 公共消息处理单元，用于接收第一用户设备发起的消息业务，并根据消息 业务请求内容，将消息业务请求发送至对应的消息业务处理单元； 消息业务处理单元，进行对应消息业务处理。 较佳地，所述消息业务处理单元进一步包括 内部消息业务处理单元，对第一消息业务进行处理；
消息业务互通单元，与外部消息业务处理单元相连，用于对第二消息业务 进行处理。较佳地，所述/〉共消息处理单元进一步包括 消息解析单元，用于解析收到的消息，获取消息体内容； 消息预处理单元，根据消息体的内容，进行公共处理； 消息调度管理单元，根据消息体的内容，将所述消息业务请求路由至对应 的消息业务处理单元。较佳地，所述公共消息处理单元进一步包括下述单元之一或组合会话管理单元，用于提供会话管理功能；呈现管理单元，用于提供用户的呈现状态管理；数据库，用于提供统一的数据库存储支持；群组管理单元，用于用户管理其加入的群组；联系人管理单元，用于用户维护其的联系人列表；网络存储单元，用于向用户提供保存各类历史消息和々某体内容的功能；业务提供和自助管理单元，用于向用户提供自助管理功能。较佳地，所述消息业务互通单元进一步包括格式转换单元，用于将消息业务请求进行格式转换并发送至外部消息系统。较佳地，所述消息业务互通单元与外部消息业务处理单元相连时与不同的外部消息业务处理单元使用不同的接口，或与所有的外部消息业务处理单元使用统一的接口。较佳地，所述内部消息业务处理单元进一步包括下述内容之一或組合MMS实现单元，用于实现多媒体消息业务；PoC实现单元，用于实现PoC业务；IM实现单元，用于实现IM业务；短消息实现单元，用于实现短消息业务；
基于IP的短消息实现单元，用于实现基于IP的短消息业务。较佳地，所述公共消息处理单元、内部消息业务处理子单元和消息业务互 通单元，可以位于同一个服务器，也可以位于不同的服务器。较佳地，所述公共消息处理单元、消息业务处理单元，可以位于同一个服 务器，也可以位于不同的服务器。较佳地，所述的系统，还包括第二用户设备，安装有第二客户端程序，用 于发起消息业务请求，所述的第一用户设备与第二用户设备可以相同，也可以 不相同。较佳地，所述内部消息处理单元和/或消息业务互通单元可以设置为多个。 较佳地，所述第一用户设备是移动终端，或个人计算机，或业务应用服务器。本发明提供了 一种融合消息系统，通过公共消息处理单元集中处理终端发 起的消息业务请求，简化了用户对消息业务的使用，改善了消息业务的体验， 方便了消息业务的实现，并促进了消息业务之间的互通，能实现传统消息到融 合消息平台的平滑演进，有益于保护现有的投资。


图1为现有技术中短消息系统在GSM网络平台中的位置示意图；图2为现有技术中MMS系统的标准构架示意图；图3为现有技术中OMA定义的基于SIPLE协议的IM系统架构示意图；图4为现有技术中OMA PoC规范的网络结构图；图5为现有技术中OMA PoC发言权申请流程示意图；图6为本发明融合消息系统结构示意图；图7和图8为本发明公共消息处理单元的结构示意图；图9和图IO为本发明消息业务处理单元的结构示意图；图1 l和图12为本发明消息业务互通单元的结构示意图；图13为本发明消息业务互通单元进行IM业务和Email业务互通设置的网络 结构示意图；图14为本发明例1的结构示意图； 图15为本发明例2的结构示意图； 图16为本发明例3的结构示意图； 图17为本发明例4的结构示意图； 图18为本发明例5的结构示意图； 图19为本发明例5的流程示意图； 图20为本发明例6的结构示意图； 图21为本发明例6的流程示意图； 图22为本发明例7的流程示意图。
具体实施方式
下面结合说明书

本发明具体实施方式
。 如图6所示，本发明融合消息系统，主要包括 用户设备IO,安装有客户端程序，用于发起消息业务请求。 该客户端程序可以基于移动设备，如手机/PDA (个人数字助理)等；也 可以基于个人电脑，还可以是基于业务应用服务器。对于基于移动设备的，其 实现方式可以采用软、硬件定制方式实现即把一定功能的软、硬件程序固化 在移动终端中，提供融合消息客户端的功能。也可以采用纯软件的方式实现 即提供基于特定移动操作系统的软件，然后通过安装或者加栽的方式在移动终 端上提供融合消息客户端功能。这种方式常见的是基于Kjava， Brew平台，或 者基于Symbians、 WinCE操作系统的软件程序。这些程序安装/升级更新和卸 载都比较容易。由于是纯软件实现，性能方面会比定制方式稍低。从客户端软件的功能上讲，主要是通过相关协议(如 SIP/SDP/RTP/RTCP/RMTP/XCAP)进行业务信令和媒体的收发，实现相应的融
合消息业务的业务逻辑，如融合消息业务的客户端状态机，相关协议功能， 用户界面，用户操作功能等。用户设备也可以是独立的业务服务器，业务服务器通过特定的接口协议向 融合消息平台发送消息业务请求，此时就是应用程序向融合消息平台发送或者 接收消息。这种场景在SP (服务提供商)与电信运营商进行业务交互的时候 最为常见，此时所述的业务服务器是归属于服务器提供商的。融合消息业务的目的是为了方便用户的业务实用，提高业务体验，因此在 界面方面集成和融合了原有消息业务的一些界面，典型地，用户可以看到一系 列用户和群组的列表，在选中某个用户或者群组对象后，可选择合适的方式发 起业务，例如可以选择短信方式，即时消息方式，PoC业务方式等。也可以在 选中某个用户或者群组对象后，仅仅输入需要发送的内容，至于采用何种方式 发送通it^户端和服务器判断完成。例如当用户发送的是图片和文字时候， 客户端或服务器就采用多媒体彩信的方式发送。当用户发送的是一个视频片断 时候，就采用即时消息的方式发送。客户端或者服务器判断采用何种方式发送 消息内容的依据可能是用户设置的，也可能是运营商设置的策略，也可能是业 务逻辑规定的。简单地说，现有消息系统采用的是确定的消息传送方式，用户想发送什么 类型的，就启用那种类型的客户端程序，要求用户熟悉各种业务的发送能力和 特点。融合消息业务的特点就是融合了各种消息业务的能力，以通过最合适的 方式把消息内容传递到接收者作为唯一 目的。融合消息可以不要求用户对各类 消息业务有深入了解，目标是用户只需要知道给谁发什么内容就可以了。当 然也支持用户指定以某种方式使用业务。公共消息处理单元20,用于接收用户设备IO发起的消息业务，并根据消 息业务请求内容，将消息业务请求发送至对应的消息业务处理单元30;消息业务处理单元30，进行对应消息业务处理。在上述架构中，本发明设置了公共消息处理单元20，用于对用户设备发起 的消息业务请求进行集中处理，如图7所示，该公共消息处理单元20可以进 一步包括消息解析单元201:解析收到的消息，去掉消息头，把消息体内容传递给 消息预处理单元202和消息调度单元203;消息预处理单元202:根据消息体的内容，进行一些公共处理，这里的处 理，包括调用公共业务部件的能力对消息、会话、用户进行管理。例如查询用 户信息数据，进行用户鉴权，分配会话标识并进行会话关联，发布更新的 Presence状态等；这里根据消息体内容进行处理的情况有如如果用户的请求中要求建立会 话类型的消息交互，则建立新的会活，并设置会话的上下文信息，如发送方 标识/接受方标识，会话支持的媒体类型等，为后续消息的处理做准备。根据策 略处理单元的处理的情况参见策略处理单元。消息调度管理单元203:根据消息体的内容，如消息请求类型，把消息转 发给消息业务处理子系统或消息业务互通子系统处理。进一步，如图8所示，所述公共消息处理单元20包括下述单元之一或组合会话管理单元204,用于向各类消息业务提供会活管理功能，例如， 一个 CM用户A向CM用户B发起IM聊天，则会话管理单元204就创建对应的会话，则 通过该单元，融合消息系统进行A和B会话的上下文管理，当A和B的聊天结束， 对应的^i舌被删除。呈现管理单元205，用于提供用户的呈现状态管理，通过呈现功能，用户 可以了解其他用户的在线状态，提升业务体l^。数据库206，用于提供统一的数据库存储支持，例如存贮用户的签约信息， 存储用户的个性化设置信息，用户的消息路由信息等；群组管理单元207，用于用户管理其加入的群组，用户可以创建/修改自己 的群组，在消息业务中进行群组聊天或者群发；
联系人管理单元208,用于用户维护其的联系人列表，用户可以维护自己 的联系人列表，不管通过什么终端，都可以把网络上的联系人列表下栽到终端 上，从而选择其中的联系人发送消息或者发起会话聊天；网络存储单元209，用于向用户提供保存各类历史消息的功能，在本发明 方案中，用户可以有多种类型的消息，该单元向用户提供了保存各类历史消息 的功能。用户可以删除，下载这些历史消息；业务提供和自助管理单元210，用于向用户提供自助管理功能，可以是提 供基于Web的服务，例如进行融合消息业务的个性化设置，修 iL/删除历史消息， 修改群组信息，修改联系人信息等等。上述自助管理功能包括用户通过系统提供的功能设置自己的业务偏好；和/或 用户根据系统提供的功能操作网络存储单元中的消息或者媒体；和/或 用户根据系统提供的功能管理其联系人列表和/或群组信息。 如上这些单元独立提供功能，这些单元可以集成在/>共消息处理子系统中，也可以是CMS外部的独立功能实体。在上述架构中，该消息业务处理单元30可以进一步细化，如图9所示，具体可以包括内部消息业务处理单元301,对内部消息业务进行处理； 消息业务互通单元302，与外部消息业务处理单元相连，用于对外部消息业务进行处理。在上述架构中，如图IO所示，内部消息业务处理单元301可以进一步包 括下述内容MMS实现单元3011,用于实现多媒体消息业务； PoC实现单元3012,用于实现PoC业务； IM实现单元3013，用于实现IM业务； 短消息实现单元3014,用于实现短消息业务。
基于IP的短消息实现单元3015，用于实现基于IP的短消息业务。 上述内部消息处理单元301的具体设置，可以依据系统要求来选择，上述各个实现单元都可以作为内部消息业务处理单元301的子模块进行方便的叠加。在上述构架中，如图ll所示，所述消息业务互通单元302进一步包括 格式转换单元3021,用于将消息业务请求进行格式转换并发送至外部消息 系统。上述消息业务互通单元302还可以进一步作如图12所示的设置 第一消息业务互通模块3022,与外部消息业务系统l相连，完成第一种消 息业务的互通；第二消息业务互通模块3023，与外部消息业务系统2相连，完成第二种消 息业务的互通。进一步，消息业务互通单元302与外部消息系统可以采用统一的接口，此 时图中互通接口 l和互通接口 2采用相同的接口协议。这种方案简化了消息业 务互通单元302对外的接口，当外部互连的消息系统增加后，无需修改与消息 业务互通单元302的接口协议。如图13所示，是消息业务互通单元进行IM业务和Email业务互通的设置， 图中设置了 IM业务互通模块和Email业务互通模块，分别与外部IM消息系 统和Email消息系统相连，完成上述两种业务的互通。上述方案中，主要的3个部分公共消息处理单元20、内部消息业务处理 单元301和消息业务互通单元302，三者之间可以灵活的设置，既可以设置于 同一个服务器内，也可以分别设置于不同的服务器内，具体设置方式可以依据 需要而定。上述方案中，用户设备IO之间的通信，可以通过同一个消息业务系统来 完成，也可以通过不同的消息业务系统完成，在通过不同的消息业务系统完成 时，终端设备之间可以具有同样的功能，也可以只具备对应用户所需的功能。
下面结合本发明方案的几种实际应用情况来进行说明。 例l如图14所示，是例l的结构示意图，例1中将公共消息处理单元20，内部消 息业务处理单元301，消息业务互通单元302设置在一个服务器内，可以称作融 合消息服务器(CMS)，在例1中通过上述设置，CMS成为融合消息的处理中 心，它既能独立处理某些消息业务请求，又能通过消息业务互通子系统实现与 外部消息的互通。对于CMS能独立处理的消息业务，此处称之为CMS的内部消 息业务，这些消息业务可以是现有的消息业务，例如IM, PoC, MMS， SMS 等，也可以是未来新产生的消息业务。消息业务互通单元302有两个主要的功能1、 通过内部消息业务处理单元301, CMS可以把其内部不支持的消息业务 请求发送到外部的对应消息系统处理，间接地实现该消息业务。例如，CMS 不支持SMS,则CMS把UE1的SMS业务请求发送给外部的短消息系统，交由短 消息系统处理。2、 通过消息业务互通单元302， CMS实现与外部消息业务系统互通。例如 CMS支持内部的IM业务，同时希望与外部的IM业务互通。此时需要通过消息 业务互通单元302与外部1M消息业务互通。例l中的各实体说明如下(1) 、 CMS:支持融合消息业务，融合消息用户可以通过CMS收发各种 类型的消息。通过CMS，不仅CM用户之间能进行消息交互，CM用户和非CM 用户之间也能进行消息交互。在例1中CMS中主要包括三部分公共消息处理单元20:负责统一处理UE1的消息请求，与UE1直接收发CM 消息。当收到CMC的请求，CMS判断如果请求的是CMS内部的消息业务，则 把请求发送给内部消息业务处理单元301处理，如杲请求的是外部的消息业务， 则发送给消息业务互通单元302处理。通过这种方式实现直接的消息业务处理 或者与外部系统实现消息互通。
内部消息业务处理单元301:负责特定消息业务的实现，例如实现IM业务 逻辑。消息业务互通单元302:负责实现与外部消息系统的互通。(2) 、外部消息系统位于CMS外部的消息业务提供系统，例如，可以 是传统的SMS短信中心，MMS消息系统，PoC服务器，移动/固定网络中的IM 服务器，Email月良务器等等。(3) 、 UE1 (CMS):支持融合消息的用户终端，可以是移动终端，也 可以是固定终端，能够与CMS交互使用融合消息业务。例如，UE1通过向CMS 发送消息，实现向普通的短信用户UE2发送短信。除了支持融合消息，UE1也 可以支持普通的消息业务。(4) 、 UE2 (支持传统消息业务)支持某类或者某几类消息业务的客 户端，可以是移动终端或者固定终端。这类用户终端通过和具体的外部消息系 统相连，进行对应的消息业务。例如，UE2是普通的移动终端，支持短消息业 务，那么外部消息系统就是短消息系统；UE2和该短信系统交互，进行短信的 收发。总体上说，CMS等于内部消息业务系统加消息业务互通网关。体现的外部 功能就是CMS能处理多种类型的消息业务。作为CMS用户，可以不必了解消息 业务具体由哪个网络实体处理。他只需要简单地把要发送的消息内容和消息接 收者告诉给CMS,余下的工作都由CMS来处理。例2在例l的方案中，消息业务互通单元302可以位于融合消息平台内部，实际 应用中也可以从融合消息平台中独立出来，位于融合消息平台的外部。如图15 所示，例2中将消息业务互通单元302设置在融合消息服务器之外，而其余部分 同例1设置，这样也可以达到同样的效果。例3在例1和例2的方案中，设置了内部消息业务处理单元301,该种划分M 于融合消息系统设置内部消息业务处理单元进^f亍内部消息处理的方案，实际上也可以不设置内部消息业务处理单元301 ，而都通过外部消息系统资源来完成 消息业务。如图16所示，即是这种方案的示意图。例3中在UE1接入的融合消 息服务器中，只设置公共消息处理单元20和消息业务互通单元302,并不设置 具体实现消息业务的消息业务处理单元，而具体实现消息业务的功能单元，都 利用已有的外部系统中的消息业务处理单元。 例4在前面3个方案中，都利用了外部消息系统来丰富、补充消息业务，如果 没有外部消息系统，只采用融合消息系统内部资源时，采用如图17所示的方案。 该方案只i殳置了公共消息处理单元20和内部消息业务处理单元301 ，这样的方 案适合于融合消息系统发展到比较成熟的阶段，融合消息系统能独立提供所有 消息业务，消息业务互通单元已经没有必要。当然，融合消息系统之间的交互 还是存在的，那不属于不同融合消息系统之间的交互。例5如图18所示，是本发明融合消息系统在实际应用中的一个组网示意图，该 方案中融合消息系统以融合消息服务器(CMS)形式出现。根据上述的融合消 息业务系统，CMS能提供两个融合消息用户之间的消息通信。其中CMS-A和 CMS-B分别是两个融合消息服务器，分别处理各自归属用户的融合消息业务。 CMC-l和CMC-2分别是两个融合消息客户端用户设备，分别归属于CMS-A和 CMS-B，他们通过移动网络进行融合消息通信。如图19所示，两个融合消息用户通信流程包括如下步骤 步骤1901: CMC-1向CMS-A发送消息发送请求，在请求中携带了要发送的 消息内容。根据CMC-1和CMS-A的能力，消息内容可以是文字，多媒体图片， 视频片断等。步骤1902: CMS-A收到请求后，进行判断处理，主要有判断CMC-1是否 有消息发起权限，检查消息接收者是否是本地用户，如果不是则查询其归属服 务器的地址。步骤1903: CMS-A向接收者所在的CMS-B转发消息。步骤1904: CMS-B收到请求后，进行判断处理，主要有判断CMC-2是否 处于业务激活中，如果不处于业务激活状态中(例如关机了)，则把消息保存 CMS-B中，例如保存在SMC用户的储存，如果不在线，判断CMC-2是否屏蔽了CMC-1的消息，判断CMC-2终端是否具备接收该媒体内容的能力。步骤1905:CMS-B向CMC-2发送消息。步骤1906:CMC-2向CMS-B发送确认消息。步骤1907:CMS-B发送确认消息。步骤1卯8:CMS-A^送确认消息。例6例6中，融合消息系统用户与传统消息系统用户之间的消息通信(CMC发 给传统消息用户)，该方案中融合消息系统以融合消息服务器(CMS)形式出 现。根据上述的融合消息业务系统，CMS能提供融合消息用户和传统消息用户 之间的消息通信。此处以融合消息用户和短消息用户之间的消息通信为例进行 说明，其中CMS-A是融合消息服务器，负责处理其归属用户的融合消息业务， SMC是短消息中心，负责处理短信业务。CMC-1和SMSUE分别是融合消息客 户端和普通的短信终端，分别归属于CMS-A和SMC，他们通过移动网络进行消 息通信。如图21所示，主要包括以下步骤步骤2101: CMC-1向CMS-A^送消息发送请求，在请求中携带了要发送的 消息内容。根据CMC-1和CMS-A的能力，消息内容可以是文字，多媒体图片， 视频片断等。步骤2102: CMS-A收到请求后，进行判断处理，根据请求消息中的指示 CMC-1希望向被叫发送短消息。步骤2103: CMS-A通过SMS-IWMSC向传统的短消息系统转发短消息。 步骤2104-步骤2107:为现有短消息处理流程，此处略。
步骤2108-步骤2109:返回确认消息。 例7例7为融合消息用户与传统消息用户之间的消息通信(传统消息用户发给 CMC),其网络结构示意图可以和图20同样设置。如图22所示，主要包括以下 步骤步骤2201:传统SMS用户通过短消息中心SMC向融合消息用户CMC-1发送 短消息。步骤2202: SMC把消息转发到GMSC。步骤2203: GMSC通过HSS查询被叫信息，被叫注册了融合消息业务，且 把融合消息设置为首选的消息接受方式，结合查询得到的路由信息将该短消息 转发给CMS-1。步骤2204: CMS-1把收到的短消息格式转化为融合消息的格式，发送给 CMC-1。步骤2205-步骤2208:返回确认消息。本发明提供了一种融合消息系统的实现方法和对应的系统架构。简化了用 户对消息业务的使用，改善了消息业务的体验，简化了消息业务的实现，简化 了消息业务之间的互通，能实现传统消息到融合消息平台的平滑演进，有益于 保护现有的投资。显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发 明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及 其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。
权利要求
1、一种融合消息系统，其特征在于，包括第一用户设备，安装有第一客户端程序，用于发起消息业务请求；公共消息处理单元，用于接收第一用户设备发起的消息业务，并根据消息业务请求内容，将消息业务请求发送至对应的消息业务处理单元；消息业务处理单元，进行对应消息业务处理。
2、 如权利要求1所述的系统，其特征在于，所述消息业务处理单元进一 步包括内部消息业务处理单元，对第一消息业务进行处理； 消息业务互通单元，与外部消息业务处理单元相连，用于对第二消息业务 进行处理。
3、 如权利要求1所述的系统，其特征在于，所述公共消息处理单元进一 步包括消息解析单元，用于解析收到的消息，获取消息体内容； 消息预处理单元，根据消息体的内容，进行公共处理； 消息调度管理单元，才艮据消息体的内容，将所述消息业务请求路由至对应 的消息业务处理单元。
4、 如权利要求l、 2或3所述的系统，其特征在于，所述公共消息处理单 元进一步包括下述单元之一或组合会话管理单元，用于提供会话管理功能； 呈现管理单元，用于提供用户的呈现状态管理； 数据库，用于提供统一的数据库存储支持；群组管理单元，用于用户管理其加入的群组；联系人管理单元，用于用户维护其的联系人列表；网络存储单元，用于向用户提供保存各类历史消息和媒体内容的功能；业务提供和自助管理单元，用于向用户提供自助管理功能。
5、 如权利要求2或3所述的系统，其特征在于，所述消息业务互通单元 进一步包括格式转换单元，用于将消息业务请求进行格式转换并发送至外部消息系统。
6、 如权利要求2或3所述的系统，其特征在于，所述消息业务互通单元 与外部消息业务处理单元相连时与不同的外部消息业务处理单元使用不同的接口，或 与所有的外部消息业务处理单元使用统一的接口 。
7、 如权利要求2或3所述的系统，其特征在于，所述内部消息业务处理 单元进一步包括下述内容之一或组合MMS实现单元，用于实现多媒体消息业务；PoC实现单元，用于实现PoC业务；IM实现单元，用于实现IM业务；短消息实现单元，用于实现短消息业务；基于IP的短消息实现单元，用于实现基于IP的短消息业务。
8、 如权利要求2或3所述的系统，其特征在于，所述公共消息处理单元、 内部消息业务处理子单元和消息业务互通单元，可以位于同一个服务器，也可 以位于不同的服务器。
9、 如权利要求1或2所述的系统，其特征在于，所述公共消息处理单元、 消息业务处理单元，可以位于同一个服务器，也可以位于不同的服务器。
10、 如权利要求l、 2或3所述的系统，其特征在于，还包括第二用户设备，安装有第二客户端程序，用于发起消息业务请求，所述的第一用户设备与 第二用户设备可以相同，也可以不相同。
11、 如权利要求2或3所述的系统，其特征在于，所述内部消息处理单元 和/或消息业务互通单元可以设置为多个。
12、 如权利要求1、 2或3所述的系统，其特征在于，所述第一用户设备是移动终端，或个人计算机，或业务应用服务器。
全文摘要
本发明公开了一种融合消息系统，包括第一用户设备，安装有第一客户端程序，用于发起消息业务请求；公共消息处理单元，用于接收第一用户设备发起的消息业务，并根据消息业务请求内容，将消息业务请求发送至对应的消息业务处理单元；消息业务处理单元，进行对应消息业务处理。本发明通过公共消息处理单元集中处理终端发起的消息业务请求，简化了用户对消息业务的使用，改善了消息业务的体验，方便了消息业务的实现，并促进了消息业务之间的互通，能实现传统消息到融合消息平台的平滑演进，有益于保护现有的投资。
文档编号H04L12/58GK101155329SQ20061014066
公开日2008年4月2日 申请日期2006年9月29日 优先权日2006年9月29日
发明者章李铭 申请人:华为技术有限公司