CN103369738B - 一种用户增值电信业务处理方法及装置 - Google Patents

Abstract

本发明提供一种用户增值电信业务处理方法及装置，以解决现有技术中存在的增值电信业务系统发送用户增值电信业务消息不可控的问题，该方法包括：增值电信业务系统接收外部网元发送的消息，当判断外部网元为非营帐系统，接收的消息为增值电信业务消息时，增值电信业务系统查询与增值电信业务消息对应的计费号码的用户状态信息，增值电信业务系统根据查询到的用户状态判断是否发送该增值电信业务消息，由于根据用户状态判断是否发送该增值电信业务消息，使得用户增值电信业务消息的发送可控。

Description

一种用户增值电信业务处理方法及装置

技术领域

本发明涉及通信技术领域，特别涉及一种用户增值电信业务处理方法及装置。

背景技术

随着短信、彩信业务的快速发展，关于欠费用户、停机用户和销户用户的短、彩信业务结算风险日益突出。根据现有运营商短彩信业务话单的生成流程，运营商增值电信业务话单在计费用户归属地短彩信中心生成，并根据相关计费结果和SP(Service Provider，服务提供商增值电信业务)进行结算。由于目前运营商短彩信中心缺乏用户状态信息，造成SP下发给欠费、停机或销户用户的短信话单照常生成，这些话单的费用也要与SP进行结算，对运营商的利益造成损失。

可见现有技术中存在彩信中心发送用户增值电信业务消息不可控的问题。

发明内容

本发明的目的是针对现有技术中存在的彩信中心发送用户增值电信业务消息不可控的问题，提供一种用户增值电信业务处理方法及装置，该方法包括：

增值电信业务系统接收外部网元发送的消息；

当判断外部网元为非营帐系统，接收的消息为增值电信业务消息时，增值电信业务系统查询与增值电信业务消息对应的计费号码的用户状态信息；

增值电信业务系统根据查询到的用户状态判断是否发送该增值电信业务消息。

进一步，还包括：

当判断外部网元为营帐系统时，增值电信业务系统根据接收的消息中相互绑定的计费号码和用户状态信息，更新用户状态表；

增值电信业务系统查询与增值电信业务消息对应的计费号码的用户状态信息具体为：

增值电信业务系统通过用户状态表查询与增值电信业务消息对应的计费号码的用户状态信息。

进一步，增值电信业务系统作为服务器端采用长连接的方式接收作为客户端的营帐系统发送的消息。

进一步，增值电信业务系统接收外部网元发送的消息具体为：

增值电信业务系统通过营帐系统消息处理线程接收外部网元发送的消息，并对消息进行鉴权；

当判断外部网元为营帐系统时，增值电信业务系统根据接收的消息中相互绑定的计费号码和用户状态信息，更新用户状态表具体为：

当鉴权消息为营帐系统发送的消息时，增值电信业务系统通过营帐系统消息处理线程向用户状态信息消息处理线程转发该消息，若用户状态信息消息处理线程根据消息格式确定该消息为营帐系统发送的握手命令，则通知营帐系统消息处理线程向营帐系统发送响应消息；

增值电信业务系统通过营帐系统消息处理线程接收并向用户状态信息消息处理线程转发，营帐系统发送的包括相互绑定的计费号码和用户状态信息的消息，用户状态信息消息处理线程进行编解码后发送给数据库访问线程；

数据库访问线程应答编解码后的消息，并更新用户状态表。

进一步，增值电信业务系统通过心跳检测保持与营帐系统的长连接，其中进行心跳检测所需的数据包由包头组成；

还包括：

当增值电信业务系统检测出与营帐系统的连接在预定的时间内空闲，则主动断开长连接。

本发明实施例还提供一种用户增值电信业务处理装置，包括：

接收模块，用于接收外部网元发送的消息；

查询模块，用于当判断外部网元为非营帐系统，接收的消息为增值电信业务消息时，查询与增值电信业务消息对应的计费号码的用户状态信息；

发送模块，用于根据查询到的用户状态判断是否发送该增值电信业务消息。

进一步，还包括：

更新模块，用于当判断外部网元为营帐系统时，根据接收的消息中相互绑定的计费号码和用户状态信息，更新用户状态表；

查询模块，还用于通过用户状态表查询与增值电信业务消息对应的计费号码的用户状态信息。

进一步，接收模块，还用于作为服务器端采用长连接的方式接收作为客户端的营帐系统发送的消息。

进一步，接收模块，还用于通过营帐系统消息处理线程接收外部网元发送的消息，并对消息进行鉴权；

查询模块，还用于当鉴权消息为营帐系统发送的消息时，通过营帐系统消息处理线程向用户状态信息消息处理线程转发该消息，若用户状态信息消息处理线程根据消息格式确定该消息为营帐系统发送的握手命令，则通知营帐系统消息处理线程向营帐系统发送响应消息，通过营帐系统消息处理线程接收并向用户状态信息消息处理线程转发，营帐系统发送的包括相互绑定的计费号码和用户状态信息的消息，用户状态信息消息处理线程进行编解码后发送给数据库访问线程，数据库访问线程应答编解码后的消息，并更新用户状态表。

进一步，接收模块，还用于通过心跳检测保持与营帐系统的长连接，其中进行心跳检测所需的数据包由包头组成，当检测出与营帐系统的连接在预定的时间内空闲，则主动断开长连接。

由于制定各营帐系统与作为增值电信业务系统的短彩信中心用户状态接口方案，用于营帐系统向短彩信中心传送用户状态信息，并由短彩信中心根据用户状态信息控制对SP下发的用户增值电信业务消息，以解决目前存在的用户增值电信业务消息下发不可控的问题。

附图说明

图1表示本发明实施例提供的方法流程图；

图2表示本发明实施例提供的彩信中心各模块的逻辑拓扑图；

图3表示本发明实施例提供的营帐系统同步用户状态信息流程图；

图4表示本发明实施例提供的彩信业务流程图。

具体实施方式

下面结合说明书附图对本发明优选实施例进行说明，以解决现有技术中存在的彩信中心发送用户增值电信业务消息不可控的问题。

本发明实施例提供的用户增值电信业务处理方法，如图1所示，该方法包括如下步骤：

步骤101、增值电信业务系统接收外部网元发送的消息。

本步骤中，增值电信业务系统可以是彩信中心、短信中心或短信网关等对增值电信业务进行处理的网元。向增值电信业务系统发送消息的网元可能是营帐系统，也可能是非营帐系统。

步骤102、当判断外部网元为非营帐系统，接收的消息为增值电信业务消息时，增值电信业务系统查询与增值电信业务消息对应的计费号码的用户状态信息。

本实施例中，增值电信业务消息以彩信为例进行说明，当然例如短信等其它增值电信业务消息也可以。

步骤103、增值电信业务系统根据查询到的用户状态判断是否发送该增值电信业务消息。

本实施例中以彩信中心作为增值电信业务系统进行说明，彩信中心在本地系统保存用户的状态主要有以下几种：1)允许发送消息；2)改号，根据原用户的状态进行控制；3)销户，直接删除用户，业务鉴权时查不到，不允许发送；4)预约销户，允许发送；5)取消预约销户，允许发送；6)开机，允许发送；7)营业停机，不允许发送；8)欠费停机，不允许发送。

通过上面的状态说明可知，当用户状态是欠费、停机或销户时，彩信中心不向处于这些状态的用户发送增值电信业务消息。

用户状态信息存储在彩信中心本地用户数据库中，可在用户数据库中新建表(用户状态表)，专门存储此类信息例如用户状态表中存有计费号码138********对应的用户状态为欠费，这样彩信中心可以通过用户状态表查询与彩信对应的计费号码的用户状态信息。

下面对彩信中心在对用户增值电信业务处理过程中涉及的各个进程进行说明，彩信中心各模块的逻辑拓扑图如图2。

数据库访问线程(dbpro)30：彩信中心原已有进程(以dbpro为例)操作数据库40，本发明实施例的方案只需要扩展dbpro的功能即可。同时在已有的内存表50中增加本地用户状态的内存表，dbpro启动时加载用户状态表中记录。

dbpro扩展后新增以下功能：1)启动时加载用户状态表中记录到内存表50中；2)与彩信中心主业务进程交互，提供给后者用户状态鉴权结果；3)接收营帐系统的用户状态信息，写入用户状态表；该功能的实现依赖于dbpro与彩信中心新增的用户状态信息消息处理线程功能模块(以mmlct命名)的消息交互；

如果彩信中心或短信中心不具备dbpro功能模块或功能，则需要另外提供该模块及功能。

mmlctl线程20：

彩信中心业务处理程序新增mmlctl处理线程。其主要功能是处理营帐系统的用户状态信息消息，并编码后送给dbpro，完成用户状态信息的本地保存；

彩信中心主业务程序60(MMSP)：

彩信中心主业务程序(MMSP)要新增以下功能：在去鉴权模块或鉴权系统鉴权之前，要先去查询本地用户状态数据库；根据查询到的计费用户的状态判断是否继续进行后续流程。是否继续进行后续流程可做到根据配置项执行。

营帐系统消息处理线程10(mmtcpctl线程)：

彩信中心增加营帐系统消息处理线程。对于外部网元建立的链接，如果IP是营帐系统的IP，将数据交给mmlctl线程。其他情况，按照以前的流程，将数据交给http模块70(承载模块)处理。

操作维护台：

彩信中心的操作维护台需要增加营帐系统的配置信息，如访问账号、密码、IP等，以便彩信中心能正常接收营帐系统的消息。

以下结合具体流程说明该方案的具体实施方法。

营帐系统同步用户状态信息流程如图3所示：

各MMSC与营帐系统之间采用长连接方式，营帐系统作为客户端，MMSC作为服务器端，由客户端主动发起建立连接并通过连接保持消息包，维护连接。当客户端要发送命令时，主动向服务器端建立连接，然后向服务器端发送命令，并接收应答；服务器端从客户端接收命令，返回应答。客户端可以同时向服务器端建立多个连接；命令及其应答之间的时间间隔可配置，超时需要重发；双方在没有消息传递时发送消息维持包保持通讯状态。

步骤201、首先客户端发起Bind命令给MMSC。

步骤202、MMSC通过mmtcpctl线程收到Bind命令后，鉴权消息包的IP，mmtcpctl线程经鉴权发现是营帐系统的消息，验证通过，向mmlctl线程转发该消息，若mmlctl线程根据消息格式确定该消息为Bind命令，则通知mmtcpctl线程给客户端发送Bind_Resp消息，双方建立链接。

步骤203、客户端此时发送包含相互绑定的计费号码和用户状态信息的UserInfo消息。

步骤204、MMSC的mmltcpctl线程收到营帐系统发送的UserInfo消息后，鉴权通过，直接转发给mmlctl线程。后者根据UserInfo消息格式确定该消息为，对UserInfo消息进行编解码后，发送UserInfoUpdate_Req消息给DBPRO进程。

步骤205、DBPRO进程先成功应答UserInfoUpdate_Req消息向mmltcpctl线程发送UserInfoUpdate_Ack消息，然后将消息写入用户状态信息库表，由于营帐系统发送的消息中包含用户状态有变化的记录。这样就更新用户状态表。

步骤206、MMSC通过mmltcpctl线程向营帐系统发送UserInfo消息的响应消息UserInfo_Resp消息。

步骤207、营帐系统向MMSC发送keepalive包。

步骤208、MMSC通过mmltcpctl线程向营帐系统发送keepalive包。

营帐系统和MMSC需要保持长连接，这样两者需要进行消息探测。客户端主动向服务器端成功建立连接之后，如果服务器端检测出连接长时间空闲，可以主动断开该连接。因此，客户端如果在空闲时间内没有数据发送，可以发送keepalive包，服务器端收到keepalive包后返回相应的keepalive响应包，从而MMSC通过心跳检测保持与营帐系统的长连接，其中进行心跳检测所需的数据包由包头组成，即KeepAlive与KeepAlive_Resp只有包头，没有包体。

步骤209、营帐系统向MMSC发送UnBind命令。

步骤210、MMSC向营帐系统发送UnBind_Resp命令。

步骤209和步骤210是在MMSC和营帐系统同步完成后，客户端主动发起解链消息，双方断开链接。

具备计费号码状态查询功能后的彩信业务流程，如图4所示。

步骤301：MMSC业务程序启动，包括DBPRO进程；

步骤302：DBPRO进程将用户状态信息从数据库表中加载到内存表中，以便后续业务流程中能快速查询；

步骤303：有外部网元提交消息到MMSC；

步骤304：消息首先提交给mmltcpctl线程。后者对消息源IP进行分析；

步骤305：判断IP是否是营帐系统网元的IP(根据MMSC的OMM中的配置信息)；如果IP是营帐系统的IP，则流程进入步骤306，否则进入步骤307。

步骤306：营帐系统同步流程。

步骤307：如果IP不是营帐系统IP，则mmltcpctl线程将消息包交给HTTP进程，后者经过简单的鉴权后，通过内部消息转发给MMP进程。

步骤308：MMSP进程判断是普通彩信消息，则立即向DBPOR进程发送查询计费号码状态的请求消息。

步骤309：DBPRO查询内存表，获取计费号码的用户状态信息。

步骤310：DBPRO是否将查询结果发回给MMSP；此处，如果DBPRO返回查询结果超时未将查询结果返回给MMSP，则流程进入步骤315，根据系统配置确定是否继续发送彩信消息；如果DBPRO返回了查询结果，则流程进入步骤311。

步骤311：MMSP分析计费用户状态信息；如果该状态允许继续发送彩信消息，则流程进入步骤312，流程与普通彩信消息发送流程相同，如果该状态允许不继续发送彩信消息，则进入步骤313。

步骤312：继续发送彩信消息。

步骤313：根据系统配置判断是否继续发送彩信消息；如果系统配置允许继续发送消息，则流程转入步骤312；否则。转入步骤314。

步骤314：禁止该彩信消息的继续发送，该业务流程结束。

步骤315：该步骤MMSP根据配置台的开关判断是否应该继续发送消息；如果配置为继续发送消息，则流程进入步骤312，消息成功发送，如果配置开关配置为不发送，则禁止该消息的发送，流程中止进入步骤314。

注意，在步骤312步骤中，包含了到MMSC外部的鉴权系统进行源用户、目的用户和计费用户的鉴权过程，即本实施例说明的本地用户状态信息查询的过程在系统鉴权过程之前进行。这样做的好处是，如果本地用户状态信息查询结果显示不允许继续发送该彩信，则不必再去鉴权系统进行鉴权操作，减轻了MMSC和鉴权系统的业务处理压力，也减轻了网络流量压力。

通过上述流程的分析可知，部署了本发明实施例方案的MMSC系统，可以实现彩信发送的控制，避免欠费用户、停机用户和销户用户仍然能使用短信和彩信业务的情况，从而减轻了运营商的经济损失，对网络流量的降低也起到了一定程度的作用。

最后应说明的是：以上实施例仅用以说明本发明的技术方案而非对其进行限制，尽管参照较佳实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对本发明的技术方案进行修改或者等同替换，而这些修改或者等同替换亦不能使修改后的技术方案脱离本发明技术方案的精神和范围。

Claims (4)

1.一种用户增值电信业务处理方法，其特征在于，包括：

增值电信业务系统接收外部网元发送的消息；

当判断外部网元为非营帐系统，接收的消息为增值电信业务消息时，增值电信业务系统查询与增值电信业务消息对应的计费号码的用户状态信息；

增值电信业务系统根据查询到的用户状态判断是否发送该增值电信业务消息；

所述方法还包括：

当判断外部网元为营帐系统时，增值电信业务系统根据接收的消息中相互绑定的计费号码和用户状态信息，更新用户状态表；

增值电信业务系统查询与增值电信业务消息对应的计费号码的用户状态信息具体为：

增值电信业务系统通过用户状态表查询与增值电信业务消息对应的计费号码的用户状态信息；

增值电信业务系统作为服务器端采用长连接的方式接收作为客户端的营帐系统发送的消息；

增值电信业务系统接收外部网元发送的消息具体为：

增值电信业务系统通过营帐系统消息处理线程接收外部网元发送的消息，并对消息进行鉴权；

当判断外部网元为营帐系统时，增值电信业务系统根据接收的消息中相互绑定的计费号码和用户状态信息，更新用户状态表具体为：

当鉴权消息为营帐系统发送的消息时，增值电信业务系统通过营帐系统消息处理线程向用户状态信息消息处理线程转发该消息，若用户状态信息消息处理线程根据消息格式确定该消息为营帐系统发送的握手命令，则通知营帐系统消息处理线程向营帐系统发送响应消息；

增值电信业务系统通过营帐系统消息处理线程接收并向用户状态信息消息处理线程转发，营帐系统发送的包括相互绑定的计费号码和用户状态信息的消息，用户状态信息消息处理线程进行编解码后发送给数据库访问线程；

数据库访问线程应答编解码后的消息，并更新用户状态表。

2.根据权利要求1所述的方法，其特征在于，增值电信业务系统通过心跳检测保持与营帐系统的长连接，其中进行心跳检测所需的数据包由包头组成；

该方法还包括：

当增值电信业务系统检测出与营帐系统的连接在预定的时间内空闲，则主动断开长连接。

3.一种用户增值电信业务处理装置，其特征在于，包括：

接收模块，用于接收外部网元发送的消息；

查询模块，用于当判断外部网元为非营帐系统，接收的消息为增值电信业务消息时，查询与增值电信业务消息对应的计费号码的用户状态信息；

发送模块，用于根据查询到的用户状态判断是否发送该增值电信业务消息；

所述装置还包括：

更新模块，用于当判断外部网元为营帐系统时，根据接收的消息中相互绑定的计费号码和用户状态信息，更新用户状态表；

查询模块，还用于通过用户状态表查询与增值电信业务消息对应的计费号码的用户状态信息；

接收模块，还用于作为服务器端采用长连接的方式接收作为客户端的营帐系统发送的消息；

接收模块，还用于通过营帐系统消息处理线程接收外部网元发送的消息，并对消息进行鉴权；

查询模块，还用于当鉴权消息为营帐系统发送的消息时，通过营帐系统消息处理线程向用户状态信息消息处理线程转发该消息，若用户状态信息消息处理线程根据消息格式确定该消息为营帐系统发送的握手命令，则通知营帐系统消息处理线程向营帐系统发送响应消息，通过营帐系统消息处理线程接收并向用户状态信息消息处理线程转发，营帐系统发送的包括相互绑定的计费号码和用户状态信息的消息，用户状态信息消息处理线程进行编解码后发送给数据库访问线程，数据库访问线程应答编解码后的消息，并更新用户状态表。

4.根据权利要求3所述的装置，其特征在于，接收模块，还用于通过心跳检测保持与营帐系统的长连接，其中进行心跳检测所需的数据包由包头组成，当检测出与营帐系统的连接在预定的时间内空闲，则主动断开长连接。