专利名称：业务消息传输方法和系统的制作方法
技术领域：
本发明涉及消息传输技术领域，特别涉及一种业务消息传输方法和系统。
背景技术：
目前网上SP(service provider业务提供商)主要通过ISMG(Intemet ShortMessage Gateway短消息网关)与SMSC(Short Message Service Center短消息中心)建立连接，与手机用户进行短信交互，为用户提供服务。如图1所示的组网架构其中DSMPData Service Management Platform数据业务管理平台；SCPService Control Point业务控制点。随着SP的数量急剧增加，现有让SP接入点集中在单机短消息网关的组网已经使得短消息网关的接入能力成为一个开展业务的瓶颈。同时随着业务量的增加，单机网关的系统已经不堪重负。
发明内容
鉴于目前存在的接入能力瓶颈，本发明提供一种通过多PROXY前置机接入的方案，以提高接入能力。针对即使配置了现有顶级硬件，有些运营商局点的单机处理能力仍然不堪重负的情况，本发明提供一种将负载在业务层灵活分配到不同的多个主处理进程进行处理的方案，可以极大提高系统处理能力。
本发明提供一种业务消息传输方法，包括步骤接入SP的PROXY1前置机接收SP发送给终端的业务消息；PROXY1对所述业务消息进行路由，将来自SP的业务消息发送到相应的SmsApp主处理进程；SmsApp对所述业务消息进行处理，将处理后的业务消息，根据被叫路由发送到接入SMSC的PROXY2前置机；PROXY2将所述处理后的业务消息根据被叫号码发送到相应的SMSC。
优选地，所述PROXY1对所述业务消息进行路由进一步为所述PROXY1对所述业务消息按SP接入码进行路由，将来自同一个SP的业务消息发送到同一个SmsApp进行处理。
优选地，所述PROXY1对所述业务消息进行路由进一步为所述PROXY1对所述业务消息按被叫号码号段进行路由，将来自相同号段的SP的业务消息发送到同一个SmsApp进行处理。
可选地，所述方法进一步包括在PROXY1接收SP发送给终端的业务消息之前，在PROXY1上设立SmsApp帐号；PROXY1对所述业务消息进行路由，将来自SP的业务消息发送到与所述PROXY1上设立的SmsApp帐号相对应的SmsApp。
优选地，所述方法进一步包括在PROXY1上对应不同的SmsApp设立不同的SmsApp帐号，每个帐号均设立一个备份帐号；当一个SmsApp出现故障时，启用其备份帐号的SmsApp处理及发送业务消息。
本发明还提供一种业务消息传输系统，包括SP和SMSC，其特征在于，还包括至少两个PROXY和至少一个SmsApp，其中在SP侧和SMSC侧分别设置至少一个PROXY，分别接入SP和SMSC；接入SP的PROXY用于接收来自SP发送给终端的业务消息，并对所接收到的业务消息进行路由，将所述业务消息发送给对应的SmsApp进行处理；SmsApp分别与接入SP的PROXY和接入SMSC的PROXY相连，对来自接入SP的PROXY的业务消息进行处理后，将所述业务消息发送给接入SMSC的PROXY，接入SMSC的PROXY将所述业务消息路由到相应的SMSC。
优选地，所述接入SP的PROXY对所接收到的业务消息进行路由为PROXY按SP接入码对所接收到的业务消息进行路由，将来自同一个SP的业务消息发送到同一个SmsApp进行处理。
优选地，所述接入SP的PROXY对所接收到的业务消息进行路由为PROXY按被叫号码号段对所接收到的业务消息进行路由，将同一个号段的业务消息发送到同一个SmsApp进行处理。
通过与现有技术相比较可以看出本发明扩展了短消息网关系统的接入能力和消息处理能力，并且具有很强的容灾能力。整个系统具有很好的可扩展性，根据业务量的增加，以及SP数量的增加可以调整SmsApp主处理进程和PROXY的数量，以满足业务开展的需要。
图1为现有技术中组网架构图；图2为本发明一实施方式的系统图；图3为本发明一实施方式的流程图；图4为本发明另一实施方式的流程图。
具体实施例方式
为使本发明要解决的技术问题、采取的技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明做进一步的详细说明。
为描述方便，下面将本发明实施方式中涉及到的术语，在这里集中解释TONType of Number地址的编码类型。
NPINumeric Plan Indicator地址的编码方案。
PIDProtocol id(协议ID)。
MTSP发起到手机的消息。
MO手机发起到SP的消息。
本发明的基本构思是鉴于目前存在的接入能力瓶颈，本发明提供一种通过多PROXY接入的方案，PROXY前置机(是简化的短消息网关，主要功能包括号码转换，路由，转发消息给主处理进程等，后面将进一步给以描述)，本方案可以在现有技术的基础上大大提高接入能力。针对即使配置了现有顶级硬件，有些运营商局点的单机处理能力仍然不堪重负的情况，本发明提供一种将负载在业务层灵活分配到不同的多个主处理进程进行处理的方案，可以大大提高系统处理能力。为描述方便，在本发明实施例中称主处理进程为SmsApp，提供类似现有网关的功能，并通过与PROXY的交互提高接入能力，实现负载均衡，并提供号码变换的功能。PROXY与SmsApp协作构成集群。
参照图2所示的业务消息传输系统包括SP和SMSC，还包括至少两个PROXY和至少一个SmsApp，其中在SP侧和SMSC侧分别设置至少一个PROXY，分别接入SP和SMSC；接入SP的PROXY用于接收来自SP发送给终端的业务消息，并对所接收到的业务消息进行路由，将所述业务消息发送给对应的SmsApp进行处理；在接入SP的PROXY上至少设立一个SmsApp帐号；SmsApp为与PROXY上设立的SmsApp帐号相对应的SmsApp。
实施例中SmsApp对所述业务消息进行处理，类似现有技术中的ISMG(参见图1所示的架构图)对接收消息进行处理的过程，这里就不再描述。
SmsApp分别与接入SP的PROXY和接入SMSC的PROXY相连，对来自接入SP的PROXY的业务消息进行处理后，将所述业务消息发送给接入SMSC的PROXY，接入SMSC的PROXY将所述业务消息路由到相应的SMSC。
接入SP的PROXY对所接收到的业务消息进行路由可以采用两种方式一种方式为PROXY按SP接入码，即主叫号码，对所接收到的业务消息进行路由；将来自同一个SP的业务消息发送到同一个SmsApp进行处理。
另一种方式为PROXY按被叫号码，通常按被叫号码号段对所接收到的业务消息进行路由，将同一个号段的业务消息发送到同一个SmsApp进行处理。
通过主被叫路由将属于某个SP号段或者手机号码号段的消息集中到同一个SmsApp处理，使得状态报告能够匹配。
下面进一步举实施例，阐述本发明实例例采用的技术方案。
一、路由方式
每条消息有源地址，目的地址，源地址即主叫地址，目的地址即被叫地址。现有短消息网关都是根据被叫地址路由的。本发明实施例中的路由方式是主叫加被叫联合起来路由，其中路由项包括主叫地址、被叫地址、主叫地址的TON、主叫地址的NPI、被叫地址的TON、被叫地址NPI、PID。具体的路由配置可以主被叫一起设置，也可以只设置主叫，也可以只设置被叫(各项均支持通配符)。本发明的实施例通过主被叫路由进行负载分担。
例如SP(A)的接入码是8888，一个用户(B)的手机号码是13600000000。A给B发消息的源地址(主叫)是8888，目的地址(被叫)是13600000000；反过来B给A发消息的源地址(主叫)是13600000000，目的地址(被叫)是8888。
实现负载分担的两种方式1、以SP接入码为核心进行负载分担接入SP的PROXY按主叫号码对MT消息进行路由，接入SMSC的PROXY按被叫号码进行路由，PROXY具有号码转换功能，将短信中心发来的消息或者回来的状态报告进行号码转换后发送到正确的SmsApp。号码转换的目的有很多种，有的是为了加上或者去掉国家码，有的是为了运营商之间互通(如移动发给电信的短消息需要加上106)，有的是为了将SP的接入码变换成手机号码。转换前后都是号码，如手机号码或者SP接入码，有可能两者之间互换，依具体运营商网络互通的设置不同而不同。PROXY将同一个SP发来的MO和状态报告消息等业务集中到一个SmsApp进行处理。在SmsApp处理完的消息根据被叫路由到正确的PROXY，然后再根据被叫发送出去。如上面所说的例子，流程可以简单描述为SP(A)-PROXY1-SmsApp1-PROXY2-SMSC(B归属的短信中心)，即在PROXY1上设置主叫8888的消息路由到SmsApp1，在PROXY2上设置被叫为8888的消息路由到SmsApp1上，这样就可以将与SP(A)相关的业务集中到SmsApp1上处理。
2、以用户手机号码的号段为核心进行负载分担接入SP的PROXY按被叫对MT消息进行路由，接入SMSC的PROXY按主叫对MO消息和状态报告消息进行路由，将同一个号段的用户的业务集中到一个SmsApp进行处理。在SmsApp处理完的消息根据被叫路由到正确的PROXY，然后再根据被叫发送出去。如上面所说的例子，流程可以简单描述为SP(A)-PROXY1-SmsApp2-PROXY2-SMSC(B归属的短信中心)，即在PROXY1上设置被叫属于136号段的消息路由到SmsApp2，在PROXY2上设置主叫属于136号段的消息路由到SmsApp2上，这样就可以将与136号段相关的业务集中到SmsApp2上处理。
通过上面的方法，可以将短消息按号段分配到不同的SmsApp进行处理，使得业务处理由几个SmsApp分担。
二、一些细节技术方案的描述1、备份帐号实现容灾这是本发明的一个重点技术，在PROXY1上建立帐号SmsApp1和SmsApp2，分别在这两个帐号下建立到SmsApp1和SmsApp2的路由，设置SmsApp1的备份帐号为SmsApp2，当SmsApp1出现故障时，它的业务全部自动转移到SmsApp2。同样SmsApp上通过相关帐号也可以实现PROXY的备份。通过PROXY和SmsApp上的备份帐号功能，实现整个集群的容灾功能。
2、整个机群同步还是异步由SmsApp决定，即SmsAppp配置成同步则整个系统就是同步的，SmsApp配置成异步则整个系统就是异步的；PROXY全部为同步。不同运营商对整个系统配置成同步还是异步有不同的要求，本实施方式可以通过对SmsApp的配置来满足此不同要求。
1)同步集群如图3所示以MT为例SP下发消息给集群形式的网关，流程描述如下SP将消息发送到接入SP的PROXY；接入SP的PROXY将消息发送给对应的SmsApp；对应的SmsApp将消息发送给对应的短信中心接入的PROXY；接入短信中心的PROXY将消息转发给对应的短信中心。
短信中心返回应答给接入短信中心的PROXY；接入短信中心的PROXY将应答转发给对应的SmsApp
SmsApp将应答转发给接入SP的PROXY；接入SP的PROXY将应答转发给SP。
这种流程的好处是可以将下级网元(短信中心)的应答情况直接反馈给SP，缺点是SP等待应答的时间较长。
2)异步集群如图4所示，以MT为例SP下发消息给集群形式的网关的流程描述SP将消息发送到接入SP的PROXY；接入SP的PROXY将消息发送给对应的SmsApp；SmsApp将应答转发给接入SP的PROXY接入SP的PROXY将应答转发给SP；对应的SmsApp将消息发送给对应的短信中心接入的PROXY；接入短信中心的PROXY将消息转发给对应的短信中心。
短信中心返回应答给接入短信中心的PROXY；接入短信中心的PROXY将应答转发给对应的SmsApp这种流程的缺点是无法将下级网元(短信中心)的应答情况直接反馈给SP，优点是SP等待应答的时间较短。
3、所有SmsApp以及PROXY可以共用一个数据库，或者几个数据库，也可以各自使用自己的数据库。数据库保存帐号路由数据，也保存在内存中超时的等待实体，等待实体是指，网关发送消息到短信中心(或者下级网关)后，将该消息保存在内存或者数据库中等待状态报告，等待状态报告的这类消息通常成为等待实体。通常只有状态报告返回，与等待实体匹配成功，并且状态报告显示消息正常下发的，才可以对该消息计费。
4、正常话单全部在SmsApp所在的机器出，PROXY可以设置自己的话单处理进程，处理传输故障时出现的异常话单。
5、SmsApp和PROXY相应的账号路由由统一的网管管理，这样方便进行账号路由的分配管理。当某个PROXY或者SmsApp出现异常情况，可以将路由账号数据同步到别的PROXY或者SmsApp。通过统一网管管理账号路由，在某个PROXY或者SmaApp异常情况下可以将路由账号数据同步到别的PROXY或者SmsApp。
本发明通过增加PROXY前置机，扩大了系统的接入能力。现有单机短消息网关的接入能力依赖于机器的物理配置以及操作系统，使得网关的接入能力有所限制。假设单台机器的接入能力上限(即在正常开展业务的情况下最多建立的接口数)是1100个接口。那么除去短信中心以及DSMP、SCP等与网关建立连接需要接口，留给SP使用的接口一般在800至900个，具体数据取决于实际组网。而按照本发明提供的集群模式组网，单个PROXY可提供给SP接口数量就可以达到800至900甚至上千个，整个系统可以提供给SP的接口数量可以随PROXY和SmsApp的增加而扩大。
通过本发明可以极大的扩展短消息网关系统的接入能力和消息处理能力，并且具有极强的容灾能力。整个系统具有极强的可扩展性，可以根据业务量的增加，以及SP数量的增加调整SmsApp和PROXY的数量，满足业务开展的需要。
以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。
权利要求
1.一种业务消息传输方法，其特征在于，包括下列步骤接入SP的PROXY1前置机接收SP发送给终端的业务消息；PROXY1对所述业务消息进行路由，将来自SP的业务消息发送到相应的SmsApp主处理进程；SmsApp对所述业务消息进行处理，将处理后的业务消息，根据被叫路由发送到接入SMSC的PROXY2前置机；PROXY2将所述处理后的业务消息根据被叫号码发送到相应的SMSC。
2.如权利要求1所述的业务消息传输方法，其特征在于，所述PROXY1对所述业务消息进行路由进一步为所述PROXY1对所述业务消息按SP接入码进行路由，将来自同一个SP的业务消息发送到同一个SmsApp进行处理。
3.如权利要求1所述的业务消息传输方法，其特征在于，所述PROXY1对所述业务消息进行路由进一步为所述PROXY1对所述业务消息按被叫号码号段进行路由，将来自相同号段的SP的业务消息发送到同一个SmsApp进行处理。
4.如权利要求1所述的业务消息传输方法，其特征在于，所述方法进一步包括在PROXY1接收SP发送给终端的业务消息之前，在PROXY1上设立SmsApp帐号；PROXY1对所述业务消息进行路由，将来自SP的业务消息发送到与所述PROXY1上设立的SmsApp帐号相对应的SmsApp。
5.如权利要求4所述的业务消息传输方法，其特征在于，所述方法进一步包括在PROXY1上对应不同的SmsApp设立不同的SmsApp帐号，每个帐号均设立一个备份帐号；当一个SmsApp出现故障时，启用其备份帐号的SmsApp处理及发送业务消息。
6.如权利要求1至5任一项所述的业务消息传输方法，其特征在于，所述方法进一步包括接入SP的PROXY1设置为两个以上，来自不同SP的业务消息接入不同的PROXY1；一个PROXY1允许接入一个、两个或者多个SP。
7.如权利要求1至5任一项所述的业务消息传输方法，其特征在于，所述方法进一步包括接入SMSC的PROXY2设置为两个以上，发往不同SMSC的业务消息接入不同的PROXY2；一个PROXY2允许接入一个、两个或者多个SMSC。
8.如权利要求1至5任一项所述的业务消息传输方法，其特征在于，所述方法为PROXY1和PROXY2配置为同步方式；SmsApp配置为异步或者同步方式。
9.如权利要求1至5任一项所述的业务消息传输方法，其特征在于，所述方法为PROXY1、PROXY2和SmsApp共用一个或者多个数据库，或者分别使用不同的数据库。
10.如权利要求1至5任一项所述的业务消息传输方法，其特征在于，所述方法进一步包括SmsApp存储并提供正常话单；PROXY1和PROXY2设置独立的话单处理进程，传送出现故障时存储并提供异常话单。
11.如权利要求1至5任一项所述的业务消息传输方法，其特征在于，所述方法进一步包括PROXY1、PROXY2和SmsApp的帐号路由由统一的网管进行分配和管理。
12.一种业务消息传输系统，包括SP和SMSC，其特征在于，还包括至少两个PROXY和至少一个SmsApp，其中在SP侧和SMSC侧分别设置至少一个PROXY，分别接入SP和SMSC；接入SP的PROXY用于接收来自SP发送给终端的业务消息，并对所接收到的业务消息进行路由，将所述业务消息发送给对应的SmsApp进行处理；SmsApp分别与接入SP的PROXY和接入SMSC的PROXY相连，对来自接入SP的PROXY的业务消息进行处理后，将所述业务消息发送给接入SMSC的PROXY，接入SMSC的PROXY将所述业务消息路由到相应的SMSC。
13.如权利要求12所述的业务消息传输系统，其特征在于，所述SmsApp进一步为接入SP的PROXY上至少设立一个SmsApp帐号；所述将所述业务消息发送给对应的SmsApp进行处理中的SmsApp为与PROXY上设立的SmsApp帐号相对应的SmsApp。
14.如权利要求12所述的业务消息传输系统，其特征在于，所述接入SP的PROXY对所接收到的业务消息进行路由为PROXY按SP接入码对所接收到的业务消息进行路由，将来自同一个SP的业务消息发送到同一个SmsApp进行处理。
15.如权利要求12所述的业务消息传输系统，其特征在于，所述接入SP的PROXY对所接收到的业务消息进行路由为PROXY按被叫号码号段对所接收到的业务消息进行路由，将同一个号段的业务消息发送到同一个SmsApp进行处理。
16.如权利要求12至15任一项所述的业务消息传输系统，其特征在于，在SP侧和SMSC侧分别设置的PROXY还用于号码转换，将来自SP或者SMSC的信息接入到与所转换的号码相对应的SmsApp。
全文摘要
本发明公开了一种业务消息传输方法和系统，用于解决现有技术中业务量增加，网关系统负担重的问题。本发明公开的方法包括步骤接入SP的PROXY1前置机接收SP发送给终端的业务消息；PROXY1对所述业务消息进行路由，将来自SP的业务消息发送到相应的SmsApp主处理进程；SmsApp对所述业务消息进行处理，将处理后的业务消息，根据被叫路由发送到接入SMSC的PROXY2前置机；PROXY2将所述处理后的业务消息根据被叫号码发送到相应的SMSC。本发明公开的系统通过增加多个PROXY前置机接入的方案，提高接入能力，实现负载均衡。
文档编号H04L12/56GK1980411SQ200610063368
公开日2007年6月13日 申请日期2006年10月27日 优先权日2006年10月27日
发明者张影, 蒋玲俐, 陈向荣, 张志龙, 信文伟, 冯黎, 段雷, 周乐儒, 黄卉, 陈银, 刘礼, 许浩渺, 梁钟琪, 刘义平 申请人:华为技术有限公司