CN1394089A

CN1394089A - 一种移动数据业务网络系统及其通信方法

Info

Publication number: CN1394089A
Application number: CN 01120019
Authority: CN
Inventors: 吴俊�; 车海平; 牛红亮; 陈亮; 解彦良
Original assignee: Huawei Technologies Co Ltd
Current assignee: Huawei Technologies Co Ltd
Priority date: 2001-07-04
Filing date: 2001-07-04
Publication date: 2003-01-29
Anticipated expiration: 2021-07-04
Also published as: CN1176556C

Abstract

本发明公开了一种移动数据业务网络系统，至少包括一个以上短信息中心(SMC)，负责处理短消息；一个以上业务控制点(SCP)，用于接受业务请求并给出应答；一个以上业务提供端(SP)，负责提供用户所需的短信服务；至少一个业务管理访问点(SMAP)，用于提供业务管理者与业务管理点(SMP)之间的接口；至少一个业务管理点(SMP)，用于实现业务的管理，同时与SCP和SMAP相连；关键在于它还包括一个以上开放业务代理(OSP)，通过OSP之间的互连来连接不同区域的SMC或SCP，一个OSP可同时与一个以上本地的SMC、SCP、SP相连，作为SMC、SCP及SP的信息中介。该网络架构支持任意点移动用户与SP互通，且使用简单方便。本发明同时公开了基于上述移动数据业务网的通信方法。

Description

一种移动数据业务网络系统及其通信方法

技术领域

本发明涉及移动数据业务通信技术，特别是指一种能支持任意点的移动用户与业务提供端(SP)互连互通的移动数据业务网络系统及其通信方法。

发明背景

随着短信业务资费的调整，以及使用支持中文手机的用户的增多，网上短信业务迅速增长。由于短信网关(ISMG)可以在业务提供商(SP)与短信息中心(SMC)之间提供一条安全、快捷的通道进行数据交换，使手机用户利用短信方式与SP进行双向通信，并接受SP提供的信息服务。因此，移动运营商纷纷着手建设各省的短信网关，到目前为止，几乎所有省都有各自自身的短信网关。然而，迄今为止建立的短信网关是相互独立的，在实现短信息的双向业务服务时，移动用户请求服务只能是通过本地短信息中心获取由业务提供商提供的信息，而尚未形成完整的网络体系，无法与异地的业务提供端相通，很难开展全国性的业务。

短信息业务(SMS)是在移动用户与业务提供端(SP)之间以短消息方式进行业务请求与受理的一种业务方式，它分为两种：一种是由移动用户(MS)发起的短信请求，称之为拉操作方式(PULL)；另一种是由业务提供端发起的短信请求，称之为推操作方式(PUSH)。但是，由于前面所述的各个短信网关相互独立、不能互连成一体的网络结构，如果用户和业务提供端处于两个不同的区域网中，就无法完成此种短信服务，使得短信息的双向业务只能在本地范围内实现，而不能支持全国范围内移动用户与业务提供端的短信息业务，因此，导致目前开展的业务基本上是PUSH类业务，而使很多双向业务，如异地短信查分、与电台合作进行短信有奖竞猜等等业务受到地域限制，而无法顺利展开。

发明内容

有鉴于此，本发明的主要目的就在于提供一种移动数据业务网络系统及其通信方法，使其能支持任何移动用户与业务提供端之间实现短信息业务的交互，同时可为移动用户提供在移动网上安全、快捷地访问因特网的各种服务。

本发明的技术方案具体是这样实现的：

一种移动数据业务网络系统，至少包括：

一个以上短信息中心(SMC)：负责上传移动用户的短信息请求，下传短信息到移动用户，并提供短信息状态报告；

一个以上业务控制点(SCP)：用于接受上传的业务请求，并根据从业务数据库中查询的结果给出相应的应答；

一个以上业务提供端(SP)：负责提供移动用户所需的短信息服务；

至少一个业务管理访问点(SMAP)：用于提供业务管理者与业务管理点(SMP)之间的接口；

至少一个业务管理点(SMP)：用于实现业务的管理，其一端与SCP相连，另一端与SMAP相连；关键在于它还包括：

一个以上开放业务代理(OSP)：通过OSP之间的互连来连接不同区域的SMC或SCP，一个OSP可同时与一个以上本地的SMC相连，且同时通过连接点(FEP)连接本地的SCP，通过应用程序接口(API)与SP相连，作为SMC、SCP以及SP的信息中介。

其中，所述的连接点(FEP)为一个连接模块，内嵌于SCP之中，用于OSP与SCP间的协议转换。所述的应用程序接口(API)为一个应用接口模块，内嵌于SP之中，用于提供统一的标准的编程接口和协议。

一种基于上述移动数据业务网实现的通信方法，该方法包括上行过程和下行过程；

其中，上行过程是移动用户(MS)使用短消息发起请求，经由短信息中心(SMC)和移动数据业务网传送到业务提供端(SP)，它至少包括以下的步骤：

a1.SMC将移动用户提交上来的业务请求短消息发给发端开放业务代理(OSP)；

b1.发端OSP将用户信息及业务信息提交SCP，并向SCP提出短消息业务路由请求；

c1.SCP对该用户提供该业务请求的可行性进行鉴权并查询收端SP的路由，然后返回路由信息；

d1.发端OSP按照路由信息将业务请求转发到收端OSP，同时向收端OSP发出转发业务短消息到SP的请求；收端OSP收到转发业务短消息到SP的请求后，向SP发送OSP下发短消息请求，得到肯定应答后收端OSP将该业务请求提交给SP，由SP受理该请求；

下行过程是SP通过移动数据业务网和SMC向MS发送短消息，它至少包括以下的步骤：

a2.SP将业务信息或处理后的响应信息提交给所连接的源OSP，同时发SP提交短消息请求给OSP；

b2.源OSP根据目的用户信息向SCP提出用户路由请求，SCP对该SP能否将请求发至目的用户以及该用户能否接受进行鉴权，并查询目的用户路由，然后返回路由信息；

c2.源OSP按照路由信息将业务信息或响应信息转发给目的OSP，并向目的OSP发OSP转发短消息到SMC的请求，目的OSP收到后，通知SCP计费，同时将收到的业务信息或响应信息提交给SMC；

d2.SMC以短消息形势下发该业务信息或响应信息给移动用户，同时给目的OSP返回下发状态报告；

e2.目的OSP根据收到的下发状态报告向SCP发出计费请求或补款请求，并将下发状态报告转发给源OSP，再由源OSP将下发状态报告转发给SP。

该上行过程和下行过程中进一步包括SMC或OSP或SCP或SP或移动用户对相应请求回复应答的过程。所述的相应请求至少包括短消息业务路由请求、转发业务短消息到SP的请求、OSP下发短消息的请求、SP提交短消息的请求、用户路由请求、OSP转发短消息到SMC的请求、计费请求、补款请求、SP授权请求。

所述的下行过程是SP响应移动用户业务请求发响应短信息给请求用户的过程，或主动发送短信息给指定移动用户的过程。

步骤b1所述的用户信息至少包括用户账号、用户路由；所述的业务信息至少包括计费方式、费率信息、业务描述。

所述OSP与SMC之间的通信采用短信息点对点协议(SMPP)标准；所述OSP、SCP、SP实体之间的通信可扩展的置标语言(XML)标准和移动数据业务网点对点协议(CMPP)。该CMPP协议为短消息业务协议，所述的短消息业务协议至少包括短消息业务路由请求及应答、转发业务短消息到SP的请求及应答、OSP下发短消息的请求及应答、SP提交短消息的请求及应答、用户路由请求及应答、OSP转发短消息到SMC的请求及应答、计费请求及应答、补款请求及应答、SP授权请求及应答。

一种基于上述移动数据业务网实现的商务付费方法，该方法至少包括以下的步骤：

a.业务提供端(SP)向所接入的开放业务代理(OSP)发出支付请求，OSP再将此支付请求转发至SCP；

b.SCP按支付请求进行计费，并向被计费的移动用户发出支付通知。

该付费方法进一步包括以下步骤：

a.SP向移动数据业务网网关OSP发起登录请求；

b.OSP收到SP的登录请求后，向SCP提出授权请求，SCP经过鉴权后，向SP发送授权请求应答；

c.SP得到授权后，即可向OSP发出支付请求。

该方法还包括以下步骤：当OSP收到SP发来的支付请求后，要向SP回复支付请求的应答；当SCP收到OSP发来的支付请求后，要向OSP回复支付请求的应答；当移动用户收到SCP发来的系统支付通知后，要向SCP回复对系统支付通知的应答。

所述OSP与SMC之间的通信采用短信息点对点协议(SMPP)标准；所述OSP、SCP、SP实体之间的通信可扩展的置标语言(XML)标准和移动数据业务网点对点协议(CMPP)。该CMPP协议为电子商务业务协议，所述的电子商务业务协议至少包括SP授权请求及应答、SP向OSP提出的支付请求及应答、OSP向SCP提出的支付请求及应答、系统支付通知及应答。

由上述技术方案可以看出，本发明的关键就是：在原有的移动智能网和短信息中心(SMC)之间增加了一个开放的、统一的管理接口层，即在SMC与智能网的业务控制点(SCP)之间增加了一个开放业务代理(OSP)及相应的连接点(FEP)和应用接口(API)，所有实体之间的通信均通过OSP代理，其作为SMC、SCP与SP之间的中介点，可用标准的接口与协议实现各个区域网之间移动用户与业务提供端的互连、互通，进而在该网络中通过短信息方式来传递移动用户和SP之间的服务请求与响应，实现移动用户与业务提供端之间的业务交互过程。让用户能够通过短信息方式访问任何一个接入网中的业务提供端，获取相应的服务，同时也让业务提供端能够发送信息到用户，并且无需关心网络细节，进而使移动用户可获得全国范围内的短信服务支持。

该系统还接受SCP的控制及使用，包括计费、支付。

本发明通信过程中所发的各种请求与应答均基于现有的XML标准格式，该XML标准是一种基于文本流的协议体系，定义了互联网上交换数据的标准，通常用于服务器与服务器之间、服务器与浏览器之间大量的数据交换，它既可以作为标准交换语言担负描述交换数据的作用，又可以作为派生其它置标语言的元语言，方便的定义各种置标语言标准。本发明方案中所述的CMPP协议即是以XML标准为元语言扩展出的移动数据业务网上的传输标准。

可见，本发明的网络系统不仅覆盖范围广、支持任意点用户与SP互通业务，且能配合多种灵活资费体系，为移动用户提供方便快捷、灵活全面的短信服务。

另外，本发明采用OSP的互连来传输用户与SP之间的大量互通信息，只有少量重要的信息通过SCP间的互连来传输，进而降低了对SCP的资源占用及整个系统的运营成本。

本发明所提供的方法不仅实现了移动网络用户与任意业务提供端之间短信息的业务互通，而且操作与应用安全、简单、方便、快捷，为用户提供更多方便。

附图说明

图1为整个移动数据业务网系统的组网结构示意图；

图2为本发明中一实施例PULL方式的上行过程流程图；

图3为一实施例PULL方式的下行过程或PUSH过程流程图；

图4为另一实施例商务支付过程的流程图；

图5为本发明中通信方法的一实施例上行过程消息流示意图；

图6为本发明中通信方法的一实施例下行过程消息流示意图；

图7为本发明中通信方法的另一实施例消息流示意图。

具体实施方式

下面结合附图及具体实施例对本发明再作进一步详细的说明。

本发明所组建的移动移动数据业务网，能为移动用户和SP提动短信息业务的请求与受理，以及电子商务的支付业务等服务；而移动用户的费用支付，包括网络通信费和短信内容费用，都统一在SCP中进行统计、核算和扣除。

图1为本发明整个移动数据业务网系统的组网结构图，如图1所示，本发明移动数据业务网中的基本实体主要包括业务控制点(SCP)、开放业务代理(OSP)、短信息中心(SMC)、业务管理接入点(SMAP)、业务管理点(SMP)、业务服务提供商(SP)，每一实体具体的功能如下所述：

SCP(Service Control Point)：业务控制点，是智能网的核心构件，它用于存储用户数据和业务逻辑，实现业务逻辑的执行、支撑用户语音维护、记录话单、访问业务数据等功能。SCP通过FEP与OSP相连接，FEP(Front End Process)是SCP和OSP间的连接点，其作为一个连接模块内嵌于SCP之中，负责SCP与OSP间的协议转换，实现SCP和OSP之间的通信。SCP通过FEP接收OSP送来的鉴权请求、计费请求、路由请求，根据请求查询业务数据库给出相应的应答。

OSP(Open Service Proxy)：开放业务代理，作为整个移动数据业务网的连接核心，负责各短信息中心的连接，短信息的转发，话单的记录，并请求其所归属的SCP进行费用统计与扣除，通过FEP与一个SCP连接。一个OSP可以同时连接多个SMC，并且，不同区域的OSP相互连接构成一个OSP层，通过不同OSP之间的直接互连，进而间接将所有本地、异地的SMC和SCP进行连接，形成一个完整的移动数据业务网络体系，以方便地开展全国性的业务，达到一点接入，全网服务的目的。

SMC(Short Message Center)：短信息中心，负责下发短信息到移动用户，上传移动用户的短信息请求，并提供短信息状态报告。

SMAP(Service Manage Access Point)：智能网的业务管理访问点，提供业务管理者与SMP间的接口，利用此接入功能能使业务管理者通过SMP管理业务。

SMP(Service Manage Point)：业务管理点，主要实现业务的管理，包括业务管理、用户管理、业务数据管理等，在本发明中与SMAP一起实现移动数据业务网络系统的运营和管理功能。

SP(Service Provider)：业务提供端，用来进行短信息服务的主动下发和对移动用户服务请求的响应，它通过API接口与OSP相连，API是一个移动数据业务网的应用程序接口，其作为一个应用接口模块内嵌于SP中，主要负责将业务提供端以统一的标准编程接口接入，并负责CMPP协议的转换和透传，实现SP在一点，即从一个接入OSP接入，便可提供全网服务。

再参见图1所示，本发明实际上就是在智能网、短信息中心和业务提供端之间增加了一个OSP代理层，该代理层通过标准的开放接口可实现本地、异地多个SMC和SCP的互连，进而使处于任何地区的移动用户和业务提供端都能互连互通，提供或接受对方的服务。在实现业务请求与受理的过程中，OSP与SMC之间的通信采用短信息点对点协议(SMPP)标准；OSP、SCP、SP实体之间的通信可扩展的置标语言(XML)标准和移动数据业务网点对点协议(CMPP)。

基于上述实体的结构与功能特性，当一个移动用户需要从SP那里获取相关信息服务时，由移动用户发起请求，属于短信息业务的PULL方式，它包括移动用户向SP发请求的上行过程如图2所示，以及SP响应请求下发信息的下行过程如图3所示：

1)移动用户用手机进入到相应的移动数据业务网菜单项中，选择想要获取的服务栏目，如股票信息，手机将该短消息请求上传到SMC。

2)SMC根据配置的路由信息，将此短消息请求发到用户端OSP。

3)用户端OSP收到此短消息请求后，立即向SCP发出业务路由请求，即该短消息请求是属于哪个SP所提供的业务。

4)用户端OSP根据业务路由的结果，将短消息请求转发到相应的SP的客户端，有必要时可转发到SP所连接的业务端OSP，由业务端OSP将请求转发到SP。

5)之后，由SP对该请求进行处理后，将服务信息如股票信息，提交给所接入的业务端OSP，业务端OSP请求SCP对该SP进行鉴权，如判断该SP是否有提交短消息的能力，并对此短消息请求进行用户路由处理，即获取该移动用户所接入的用户端OSP的地址。

6)业务端OSP将短消息转发到用户端OSP，用户端OSP请求其接入的SCP进行计费处理，收到SCP返回的肯定应答后，然后将短消息请求转发到其接入的SMC处。

7)SMC将此短消息下发到移动用户的终端--手机上，然后给业务端OSP返回短消息下发的状态报告，业务端OSP根据状态报告，给予SCP计费数据的确认信息，给以SP提交短消息的应答。

当SP需要向移动用户主动推送服务信息时，由SP主动发起请求，属于短信息业务的PUSH方式，其具体交互过程如图3所示：

1)SP将提交短消息的请求提交到其所接入的OSP处，OSP请求SCP对该SP进行鉴权，如判断该SP是否有提交短消息的能力，并对此短消息请求进行用户路由处理，即获取该移动用户所接入的OSP的地址。

2)OSP将短消息转发到目的OSP，目的OSP请求其接入的SCP进行计费处理，收到SCP返回的肯定应答后，然后将短消息请求转发到其接入的SMC处。

3)SMC将此短消息下发到移动用户的终端--手机上，然后给OSP返回短消息下发的状态报告，OSP根据状态报告，给予SCP计费数据的确认信息，给以SP提交短消息的应答。

本发明的移动数据业务网络系统还可以支持电子商务的业务，移动用户可以用手机来进行电子商务支付活动，如：SP所提供的消费服务，小件商品的购买等等，其具体的实现流程如图4所示：

1)首先SP请求登录到其接入的OSP上，OSP请求SCP给SP授权，SP登录成功后才能继续往下处理。

2)移动用户对SP所提供的消费业务提出请求，SP进行相应的业务处理后，向其接入的OSP提出支付请求。

3)OSP请求SCP对SP进行鉴权处理，确定是合法的SP用户后，向SCP提出支付请求。

4)SCP进行相应的扣费处理，然后通知移动用户接入的OSP进行系统支付通知。

5)目的OSP以短消息的形式通知用户已经支付，并要求SMC下发短消息到用户手机终端，并提供状态报告。

由此可见，本发明的网络架构不仅支持移动网络用户与任意点的业务提供端通过短信方式互通业务，而且该方法的操作与应用安全、简单、方便、快捷，为用户提供更多方便。

那么，在本发明的移动数据业务网络系统中，按照上述几种短信息业务方式通信时，以CMPP协议完成的消息流传递过程如图5～图7所示。以一个深圳用户请求一个移动数据业务网服务为例，该用户想从北京的新浪服务提供商处获取相关的服务业务，如图5、图6所示，其相关的具体消息流如下：

1)SMC将该业务请求转发到深圳的OSP，此时深圳OSP向其接入的SCP请求业务路由，以获取相应的新浪SP所连接的目的OSP的地址。此时OSP将发送如下消息体来向SCP请求业务路由：

  ＜gw-scp＞
   ＜！--本OSP在网络中的标识，全网唯一＞
   ＜svc-routing  gw-id＝″szgw1″＞

　　    ＜！--请求该业务的移动用户的手机号码＞

　　    ＜src＞＜addr val＝″13828812345″＞＜/addr＞＜/src＞

　　    ＜！--新浪的服务代码，可能还有业务代码，SP的唯一标识＞

　　    ＜dst＞＜addr val＝″8888001″＞＜/addr＞＜/dst＞
   ＜/svc-routing＞
  ＜/gw-scp＞

2)SCP查询数据库中的路由信息后，给深圳OSP返回一个应答，指出新浪SP所在的北京OSP的地址。比如返回如下消息体：

  ＜gw-scp＞
   ＜svc-routing-rsp

　　   ＜！--SP标识，如新浪为8888＞

　　   sp-usr＝″8888″

　　   ＜！--SP业务代码，如股票查询＞

　　   srv-code＝″001″

　　   ＜！--SP所归属的OSP，如北京的OSP＞

　　   gw-id＝″bjgw1″

　　   ＜！--此路由信息能缓存的时间＞

　　   ttl＝″60″

　　   ＜！--状态码，标识此为成功的应答＞

　　   stat＝″0″＞
   ＜/svc-routing-rsp＞
  ＜/gw-scp＞

3)深圳OSP收到SCP的路由应答后，根据结果，将深圳移动用户的业务请求转发到目的北京OSP。发送如下消息体到目的OSP：

  ＜gw-gw＞

　　＜！--指明SP在SCP中的帐号，源OSP和目的OSP＞

　　＜sm-fwd-sp sp-usr＝″sina-sms″src＝″szgw1″dst＝″bjgw1″＞

　　    ＜sm esm＝″0″dcs＝″0″len＝″120″＞

　　    ＜！--业务请求最终到达的SP(新浪)的标识，全网唯一＞

　　    ＜dst＞＜addr val＝″8888″＞＜/addr＞＜/dst＞

　　    ＜！--业务请求短消息的编码方式和编码后的具体内容＞

　　    ＜sm-cont cod＝″BASE64″data＝″AABBCCDDEEFF″＞＜/sm-cont＞

　　  ＜/sm＞

　　＜/sm-fwd-sp＞
  ＜/gw-gw＞

4)北京OSP直接将业务请求短消息下发给由sp-usr所标识的新浪SP，然后给深圳OSP返回一个下发成功的应答。下发短消息的消息体如下：

  ＜gw-sp＞

　　 ＜gw-dvr＞

　　    ＜sm esm＝″0″dcs＝″0″len＝″120″＞

　　    ＜src＞＜addr val＝″13828812345″＞＜/addr＞＜/src＞

　　    ＜dst＞＜addr val＝″8888″＞＜/addr＞＜/dst＞

　　    ＜！--业务短消息编码方式和编码后的具体内容＞
　　    ＜sm-cont cod＝″BASE64″data＝″AABBCCDDEEFF″＞＜/sm-cont＞

　　   ＜/sm＞

　　   ＜！--计费信息，手机号码，费率，计费方式(按月、按条)＞

　　   ＜chg-info msid＝″13828812345″rate＝″10″type＝″1″＞

　　     ＜desc cod＝″BASE64″data＝″FFGGHHIIJJKK″＞＜/desc＞

　　   ＜/chg-info＞

　　 ＜/gw-dvr＞
  ＜/gw-sp＞

5)北京的新浪提供商响应该深圳移动用户的业务请求，该新浪SP对短消息请求进行了业务处理后，需要向用户返回业务处理结果，则新浪SP以短消息的方式提交给其接入的北京OSP，消息体如下：

  ＜gw-sp＞

　　   ＜！--业务类型和业务操作码＞

　　   ＜sp-sub svc-t＝″001″op-t＝″1111″＞

　　      ＜sm esm＝″0″dcs＝″0″len＝″100″＞

　　      ＜src＞＜addr val＝″8888″＞＜/addr＞＜/src＞

　　      ＜dst＞＜addr val＝″13828812345″＞＜/addr＞＜/dst＞

　　      ＜！--业务短消息编码方式和编码后的具体内容＞

　　      ＜sm-cont cod＝″BASE64″data＝″AABBCCDDEEFF″＞＜/sm-cont＞

　　   ＜/sm＞

　　   ＜！--计费信息，手机号码，费率，计费方式(按月、按条)＞

　　   ＜chg-info msid＝″13828812345″rate＝″15″type＝″1″＞

　　      ＜desc cod＝″BASE64″data＝″FFGGHHIIJJKK″＞＜/desc＞

　　   ＜/chg-info＞

　　＜/sp-sub＞
  ＜gw-sp＞

6)北京OSP向SCP请求用户路由信息，以确定该短消息由哪个OSP进行转发处理，转发到移动用户终端。路由请求消息体如下：<gw-scp>

<usr-routing sp-usr＝″sina-sms″svc-t＝″001″op-t＝″1111″gw-id＝″bjgw1″>

<！--用户的手机号码>

</usr-routing></gw-scp>

7)SCP查询数据库中的用户路由信息，给北京OSP返回路由应答，应答消息中包含手机用户接入的深圳OSP和深圳SMC的地址。应答消息体如下：

  ＜gw-scp＞

　　 ＜usr-routing-rsp

　　     ＜！--手机用户接入的SMC(深圳)的地址＞

　　     smc-addr＝″13800755500″

　　     ＜！--手机用户接入的OSP(深圳)的地址，全网唯一标识＞

　　     gw-id＝″szgw1″

　　     ＜！--标识此为成功应答＞

　　     status＝″0″＞

　　     ＜！--该OSP和SMC所接入的用户号码段＞

　　     ＜code-area＞＜addr val＝″138288″＞＜/addr＞＜/code-area＞

　　 ＜/usr-routing-rsp＞
  ＜/gw-scp＞

8)北京OSP根据路由结果，请求深圳OSP转发此短消息到指定深圳SMC，再由深圳SMC下发短消息到移动用户。转发请求消息体如下：

  ＜gw-gw＞

　　 ＜sm-fwd-smc sp-usr＝″sina-sms″svc-t＝″001″op-t＝″1111″

　　    ＜！--目的SMC(深圳)的地址＞

　　    smc-addr＝″13800755500″

　　    ＜！--请求转发的源OSP(北京)标识＞

　　    src-gw＝″bjgw1″＞

　　    ＜sm esm＝″0″dcs＝″0″len＝″120″＞

　　      ＜！--用户的手机号码＞

　　      ＜dst＞＜addr val＝″13828812345″＞＜/addr＞＜/dst＞

　　      ＜！--业务短消息编码方式和编码后的具体内容＞

　　      ＜sm-cont cod＝″BASE64″data＝″AABBCCDDEEFF″＞＜/sm-cont＞

　　    ＜/sm＞

　　    ＜！--计费信息，手机号码，费率，计费方式(按月、按条)＞
        <!-- SIPO <DP n="14"> -->
        <dp n="d14"/>
　　    ＜chg-info msid＝″13828812345″rate＝″15″type＝″1″＞

　　        ＜desc cod＝″BASE64″data＝″FFGGHHIIJJKK″＞＜/desc＞

　　    ＜/chg-info＞

　　  ＜/sm-fwd-smc＞
  ＜/gw-gw＞

9)深圳OSP收到转发请求后，立即请求其接入的SCP进行计费处理，再得到计费请求的肯定应答后，才请求深圳SMC下发短消息给用户。计费请求消息体如下：

  ＜gw-scp＞

　　 ＜sm-chg-req

　　  ＜！--SP(新浪)帐号，业务编码，业务操作码，记录流水号＞

　　  sp-usr＝″sina-sms″svc-t＝″001″op-t＝″1111″rid＝″4C0A0″

　　  ＜！--源OSP(北京)的标识，全网唯一＞

　　  src-gw＝″bjgw1″

　　  ＜！--目的OSP(深圳)的标识，全网唯一＞

　　  gw-id＝″szgw1″

　　  ＜！--目的SMC(深圳)的地址＞

　　  smc-addr＝″13800755500″

　　  pri＝″0″＞

　　  ＜！--接收短消息的手机号码＞

　　  ＜dst＞＜addr val＝″13828812345″＞＜/addr＞＜/dst＞

　　  ＜！--计费信息，手机号码，费率，计费方式(按月、按条)＞

　　  ＜chg-info msid＝″13828812345″rate＝″15″type＝″1″＞＜/chg-info＞

　　 ＜/sm-chg-req＞
  ＜/gw-scp＞

10)深圳OSP在得到计费的肯定应答后，通过SMPP协议将短消息转发到指定的深圳SMC，最终由深圳SMC将短消息下发到深圳移动用户的终端---手机上。

11)当深圳SMC给予深圳OSP下发短消息的状态报告时，深圳OSP根据报告状态的结果向SCP发送补款确认请求，确认计费或取消计费。请求的消息体如下：<gw-scp><！--请求计费时的记录流水号，确认计费状态，请求计费OSP标识><sm-cnfm-req rid＝″4C0A0″state＝″1″gw-id＝″szgw1″></sm-cnfm-req></gw-scp>

至此，该深圳移动用户和北京新浪SP的整个业务交互过程，包含上行和下行过程就全部结束了。通过此通信过程，该深圳移动用户即可获得北京新浪服务商提供的服务，整个操作过程方便、快捷、简单。

短消息的PUSH方式与PULL方式的下行过程完全一样，只是短信息请求的主动发起方不同。

本发明的网络结构还支持移动用户的电子商务的业务，比如：当移动用户消费了SP提供的服务，或者进行电子商务活动时，用户需要向SP支付一定的费用，如图7所示，其涉及到CMPP协议的消息流如下所述：

1)首先保证SP已经登录到了移动数据业务网中，即SP先向移动数据业务网网关OSP发起登录请求，OSP接收到SP的登录请求后，向SCP提出授权请求，经过SCP鉴权认证后，由SCP发授权请求应答给SP允许其登录。为了保证SP登录过程的安全性以及整个交易过程的可靠性，对SP登录过程进行相应的加密处理，因该加密过程不是本发明的重点，在此不再描述。

2)SP需要向移动用户收取一定的费用时，就请求OSP进行支付活动，消息体如下：

  ＜gw-sp＞

　　 ＜sp-pay-req sp-usr＝″sina-sms″svc-t＝″001″op-t＝″11″sid＝″4″op＝″1″＞

　　     ＜！--接收短消息的手机号码＞

　　     ＜dst＞＜addr val＝″13828812345″＞＜/addr＞＜/dst＞
        <!-- SIPO <DP n="16"> -->
        <dp n="d16"/>
　　   ＜！--计费信息，手机号码，费率，计费方式(按月、按条)＞

　　   ＜chg-info msid＝″13828812345″rate＝″50″type＝″1″＞

　　       ＜desc cod＝”0”data＝″AABBCCDD″＞＜/desc＞

　　   ＜/chg-info＞

　　 ＜/sp-pay-req＞
  ＜/gw-sp＞

3)OSP在收到支付请求后，立即向SCP提出支付请求，对指定用户进行扣费处理，消息体如下：

  ＜gw-scp＞

　　 ＜gw-pay-req sp-usr＝″sina-sms″svc-t＝″001″op-t＝″11″sid＝″4″＞

　　     ＜！--接收短消息的手机号码＞

　　     ＜dst＞＜addr val＝″13828812345″＞＜/addr＞＜/dst＞

　　     ＜！--计费信息，手机号码，费率，计费方式(按月、按条)＞

　　     ＜chg-info msid＝″13828812345″rate＝″50″type＝″1″＞

　　           ＜desc cod＝”0”data＝”ABCD”＞＜/desc＞

　　     ＜/chg-info＞

　　  ＜/gw-pay-req＞
  ＜/gw-scp＞

4)SCP在进行扣费成功后，需要通知移动用户支付已经成功，SCP给被计费的手机用户所接入的OSP发送系统支付通知，由OSP发往其所接入的SMC，最终再由SMC将通知发送到用户终端上。消息体如下：

  ＜gw-scp＞

　　  ＜sys-ntf smc-addr＝″13800755500″dst-gw＝″szgw1″＞

　　      ＜sm esm＝″0″dcs＝″0″len＝″120″＞

　　      ＜src＞＜addr val＝”8888”＞＜/addr＞＜/src＞

　　      ＜！--接收短消息的手机号码＞

　　      ＜dst＞＜addr  val＝″13828812345″＞＜/addr＞＜/dst＞

　　      ＜sm-cont cod＝″0″data＝″AABBCCDDEEFF″＞＜/sm-cont＞
        <!-- SIPO <DP n="17"> -->
        <dp n="d17"/>
　　     ＜/sm＞

　　  ＜/sys-ntf＞
  ＜/gw-scp＞

至此，由SP方自动扣除为移动用户提供服务的费用，同时向移动用户发出支付通知的电子商务支付活动就已经完成。

在本发明的网络结构中的OSP是与SMC相连，该OSP也可与非结构化补充业务数据中心(USSDC)相连，实现移动用户与业务提供端间的短信业务。

总之，以上所述仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。

Claims

1、一种移动数据业务网络系统，至少包括：

至少一个业务管理点(SMP)：用于实现业务的管理，其一端与SCP相连，另一端与SMAP相连；其特征在于它还包括：

2、根据权利要求1所述的网络架构，其特征在于：所述的连接点(FEP)为一个连接模块，内嵌于SCP之中，用于OSP与SCP间的协议转换。

3、根据权利要求1所述的网络架构，其特征在于：所述的应用程序接口(API)为一个应用接口模块，内嵌于SP之中，用于提供统一的标准的编程接口和协议。

4、一种基于上述移动数据业务网实现的通信方法，其特征在于该方法包括上行过程和下行过程；

5、根据权利要求4所述的通信方法，其特征在于：所述的上行过程和下行过程中进一步包括SMC或OSP或SCP或SP或移动用户对相应请求回复应答的过程。

6、根据权利要求5所述的通信方法，其特征在于：所述的相应请求至少包括短消息业务路由请求、转发业务短消息到SP的请求、OSP下发短消息的请求、SP提交短消息的请求、用户路由请求、OSP转发短消息到SMC的请求、计费请求、补款请求、SP授权请求。

7、根据权利要求4所述的通信方法，其特征在于：所述的下行过程是SP响应移动用户业务请求发响应短信息给请求用户的过程，或主动发送短信息给指定移动用户的过程。

8、根据权利要求4所述的通信方法，其特征在于：步骤b1所述的用户信息至少包括用户账号、用户路由；所述的业务信息至少包括计费方式、费率信息、业务描述。

9、根据权利要求4所述的通信方法，其特征在于：所述OSP与SMC之间的通信采用短信息点对点协议(SMPP)标准；所述OSP、SCP、SP实体之间的通信可扩展的置标语言(XML)标准和移动数据业务网点对点协议(CMPP)。

10、根据权利要求9所述的通信方法，其特征在于：所述的移动数据业务网点对点协议为短消息业务协议。

11、根据权利要求10所述的通信方法，其特征在于：所述的短消息业务协议至少包括短消息业务路由请求及应答、转发业务短消息到SP的请求及应答、OSP下发短消息的请求及应答、SP提交短消息的请求及应答、用户路由请求及应答、OSP转发短消息到SMC的请求及应答、计费请求及应答、补款请求及应答、SP授权请求及应答。

12、一种基于上述移动数据业务网实现的商务付费方法，其特征在于该方法至少包括以下的步骤：

13、根据权利要求12所述的付费方法，其特征在于该方法进一步包括以下步骤：

a.SP向移动数据业务网网关OSP发起登录请求；

c.SP得到授权后，即可向OSP发出支付请求。

14、根据权利要求12所述的付费方法，其特征在于该方法还包括以下步骤：当OSP收到SP发来的支付请求后，要向SP回复支付请求的应答；当SCP收到OSP发来的支付请求后，要向OSP回复支付请求的应答；当移动用户收到SCP发来的系统支付通知后，要向SCP回复对系统支付通知的应答。

15、根据权利要求12所述的付费方法，其特征在于：所述OSP与SMC之间的通信采用短信息点对点协议(SMPP)标准；所述OSP、SCP、SP实体之间的通信可扩展的置标语言(XML)标准和移动数据业务网点对点协议(CMPP)。

16、根据权利要求15所述的付费方法，其特征在于：所述的移动数据业务网点对点协议为电子商务业务协议。

17、根据权利要求16所述的付费方法，其特征在于：所述的电子商务业务协议至少包括SP授权请求及应答、SP向OSP提出的支付请求及应答、OSP向SCP提出的支付请求及应答、系统支付通知及应答。