一种短消息中心提醒方法及短信网关与流程

文档序号:15926666发布日期:2018-11-14 01:12阅读:532来源:国知局

本发明涉及通信领域,尤其涉及一种短消息中心提醒方法及短信网关。

背景技术

短消息网关与短消息中心是一同为签约用户提供短消息服务的网元,其中,短消息中心能实现短消息的接收、存储、转发、短消息报告生成、短消息查询以及短消息计费等功能。短消息网关则可以提供不同短消息系统之间的选路与互通功能。传统电路域的短消息主要由短消息中心提供,采用no.7信令承载;而ip短消息则采用sip(sessioninitiationprotocol,会话初始协议)message(消息)实现。为了减少对现网电路域和ims域的改造,重用传统短消息机制,ims(ipmultimediasubsystem,ip多媒体业务的子系统)网络中引入ip-sm-gw(ip-short-message-gateway,网际协议短信网关)提供ip短消息业务,其系统组网结构图可以参见图1。

网际协议短信网关11提供基于ip的ue(userequipment,用户设备)12和smsc(shortmessageservicecenter,短消息服务中心)13之间收发短消息的协议交互。当用户在发送终端上编辑短消息并选择发送后,短消息将会被传递到短信中心。短信中心接收到该短消息之后将会把该短消息发送给接收终端侧的网际协议短信网关11,网际协议短信网关11会将该短信传递给对应网元以投递给接收终端。当接收终端因关机或信号差等因素而无法接收到短消息时,针对该短消息的投递就会失败。针对短消息投递失败的情况,在3gpp标准(详请参见3gppts23.204)中制定了订阅接收终端可达的机制:短信投递失败后,网际协议短信网关11向hlr/hss(homelocationregister/homesubscriberserver,归属位置寄存器/归属用户服务器)14发送短信投递状态报告(map-report-sm-delivery-status),并向hss订阅接收终端的可达性。在接收终端可达后,网际协议短信网关11会收到归属位置寄存器/归属用户服务器14的通知。接收到可达性通知之后,网际协议短信网关11向归属位置寄存器/归属用户服务器)14发送map-ready-for-sm。归属位置寄存器/归属用户服务器14接收到消息后,向短信中心触发alertsc(短消息中心提醒)流程,以供短信中心重发之前投递失败的短消息。具体过程可以参见图2所示出的交互图:

s202、ip-sm-gw向hlr/hss发送短消息投递状态报告并订阅接收终端的可达通知。

在状态报告中包含有短消息投递结果,在该示例当中,短消息是投递失败的。ip-sm-gw通过向hlr/hss发送map-any-time-modification来订阅接收终端的可达性。

s204、hlr/hss指示mme(mobilitymanagemententity,移动性管理实体)上报接收终端可达性。

如果接收终端已在mme注册,则hlr/hss可以向mme发送idr请求消息(ue可达性通知),指示mme上报接收终端的可达性。如果接收终端没有在mme注册,则hlr/hss不发送请求消息。

s206、mme通知hlr/hss接收终端可达。

当接收终端可达时,mme通过nor通知hlr/hss该接收终端可达。

s208、hlr/hss向ip-sm-gw发送可达通知。

hlr/hss根据mme的nor通知确定接收终端可达时,根据ip-sm-gw先前的订阅向ip-sm-gw发送可达通知。

s210、ip-sm-gw向hlr/hss发送map-ready-for-sm消息。

ip-sm-gw根据可达通知了解到接收终端可达后,就确定可以向该接收终端重新投递短消息了,因此,此时可以通过map-ready-for-sm告知hlr/hss向sc触发alertsc流程。

s212、hlr/hss向sc触发alertsc流程。

hlr/hss接收到map-ready-for-sm后,可以触发短信中心重新安排针对该接收终端的失败短信的投递。

根据上述介绍,可以了解现有触发短消息中心提醒的过程依赖于hlr/hss向ip-sm-gw告知接收终端可达性,一旦hlr/hss不支持ip-sm-gw的可达性订阅,则基于该方案无法实现失败短消息的投递。另一方面,ip-sm-gw向hlr/hss进行接收终端可达性订阅需要hlr/hss、mme等多个网元的相互配合,因此增加了这些网元的处理负担,不利于处理资源的优化配置。



技术实现要素:

本发明实施例提供的短消息中心提醒方法及短信网关,主要解决的技术问题是:提供一种新的、不依赖于向hlr/hss进行接收终端可达性订阅的短消息中心提醒的触发方案,用以解决现有技术中短消息中心提醒必须依赖于hlr/hss提供可达性订阅,不利于实现处理资源优化配置的问题。

为解决上述技术问题,本发明实施例提供一种短消息中心提醒方法,包括:

短信网关基于接收终端在应用服务器的注册确定所述接收终端可达;

所述短信网关获获取针对所述接收终端待重投短消息所存储的失败投递记录,所述失败投递记录由所述短信网关向所述接收终端投递该待重投短消息失败时生成;

所述短信网关根据所述失败投递记录触发短消息中心提醒,以指示短消息中心重新向所述接收终端投递所述待重投短消息。

本发明实施例还提供一种短信网关,包括:

记录模块,用于在向接收终端投递短消息投递失败后,存储针对该待重投短消息的失败投递记录;

确定模块,用于基于接收终端在应用服务器的注册确定所述接收终端可达;

获取模块,用于获取针对所述接收终端待重投短消息所存储的失败投递记录;

提醒模块,用于根据所述失败投递记录触发短消息中心提醒,以指示短消息中心重新向所述接收终端投递所述待重投短消息失。

本发明实施例还提供一种计算机存储介质,所述计算机存储介质中存储有计算机可执行指令,所述计算机可执行指令用于执行前述的任一项的短消息中心提醒方法。

本发明的有益效果是:

本发明实施例提供的短消息中心提醒方法及短信网关、计算机存储介质,短信网关基于接收终端在应用服务器的注册确定接收终端可达,并获取针对接收终端待重投短消息所存储的失败投递记录,然后根据失败投递记录触发短消息中心提醒,以告知短消息中心重新向接收终端投递待重投短消息。本实施例提供的方案利用了短信网关能够直接了解获知接收终端在应用服务器上的注册,因此,短信网关在不向hlr/hss订阅接收终端可达性的情况下就可以直接了解到接收终端在何时可达。当短信网关确定接收终端可达时,其获取预先记录存储的关于该接收终端的失败投递记录,并根据该失败投递记录触发短消息中心提醒。由于实现短消息中心提醒的过程不需要hlr/hss提供终端可达性,所以降低了对hlr/hss的功能要求,相对于现有方案,应用场景更广泛;同时,因为获知终端可达性不需要hlr/hss与mme等交互、配合,节省了系统的通信资源与处理资源,有利于资源的优化配置。

附图说明

图1为包含有网际协议短信网关的短信系统的一种系统组网示意图;

图2为现有技术进行短消息中心提醒的一种交互流程图;

图3为本发明实施例一提供的短消息中心提醒方法的一种流程图;

图4为本发明实施例一提供的短信网关根据失败投递记录触发短消息中心提醒的一种流程图;

图5为本发明实施例二提供的短消息中心提醒方法的一种流程图;

图6为本发明实施例三种提供的存储失败投递记录的一种交互流程图;

图7为本发明实施例三种提供的接收终端初次注册情境下进行短消息中心提醒的一种交互流程图;

图8为本发明实施例三种提供的接收终端刷新注册情境下进行短消息中心提醒的一种交互流程图;

图9为本发明实施例四中提供的短信网关的一种结构示意图;

图10为本发明实施例五中提供的短信网关的一种结构示意图;

图11为本发明实施例六中提供的一种用于部署短信网关的服务器的硬件结构示意图。

具体实施方式

下面通过具体实施方式结合附图对本发明实施例作进一步详细说明。

实施例一:

由于现有技术中在短消息投递失败之后进行短消息中心提醒依赖于hlr/hss向ip-sm-gw提供接收终端可达订阅的服务,进而造成短消息中心提醒要求hlr/hss必须支持可达性订阅,同时,因为hlr/hss提供可达订阅时需要与mme进行交互、配合才能实现,需要占用二者大量的处理资源与通信资源,所以不利于资源的优化配置。针对这些问题,本实施例提供一种短消息中心提醒方法,请参见图3示出的短消息中心提醒方法的流程图:

s302、短信网关基于接收终端在应用服务器的注册确定接收终端可达。

假定发送终端向接收终端发送了一条内容为“你周六有时间吗?”的短消息,则当发送终端选择发送之后,该短消息首先会被传递到短消息中心,由短消息中心安排接收终端侧的短信网关对该短消息进行投递。如果短信网关投递短消息的时候,接收终端处于关机或者因通信质量极差而无法接通的状态,则短信网关的投递就会失败。在通常情况下,一条短消息投递失败之后意味着该短消息需要被重新投递。

所以本实施例中的短信网关会在投递失败的时候记录下针对该失败短消息,也即待重投短消息的失败投递记录,以便在对应接收终端可达的时候,再次进行该待重投短消息的投递。短信网关存储的失败投递记录可表征是哪条短消息待重投,而不用记录失败短消息的具体内容是什么,因为失败短消息的具体内容由短消息中心记录。

虽然失败投递记录是短信网关在触发短消息中心提醒时所需要的,也即,失败投递记录是短信网关本身所需要的,因此理论上,失败投递记录应当被存储在短信网关上,但由于一个终端从关机状态进入开机状态之后,会到as上进行一次注册,该注册过程被称为初次注册,终端初次注册的时候,短信网关本地存储的针对该终端的数据将会被清除掉。而应当理解的是,在待重投短消息重新投递成功之前,针对该待重投短消息的失败投递记录都是必要的,所以短信网关不能仅仅将失败投递记录存储在本地,其至少应当将该失败投递记录存储在一个不会随意被清除的地方。所以,本实施例中,短信网关会将失败投递记录存储一份到hlr/hss上。不过应当理解的是,除了hlr/hss,短信网关还可以将失败投递记录存储到其他外部存储器上,只要该存储位置中的数据不会随着终端的开关机而被删除即可。

另外,由于需要使用失败投递记录的短信网关本身,而只要接收终端暂时不到应用服务器上进行初次注册,则短信网关并不会将本地存储的针对该接收终端的数据进行清除,所以,在本实施例中,还可以将失败投递记录存储一份在短信网关本地,这样,只要接收终端不进行初次注册,短信网关在需要获取失败投递记录的时候,就可以从本地获取到,相对于在任何情况下都从外部存储位置获取失败投递记录的做法,能够很好的避免从外部存储位置获取失败投递记录需要花费大量时间的问题。

应当理解的是,短信网关对待重投短消息进行重新投递的时机并不是由短消息中心或短信网关随机确定的,而是由接收终端确定的。只有当接收终端可达时,短信网关才会触发短消息中心提醒,通知短消息中心重新安排对失败短消息的投递。本实施例中,短信网关可以直接从as(applicationserver,应用服务器)获取接收终端可达的信息,取代向hlr/hss进行接收终端可达性订阅的做法。当接收终端从关机状态进入开机状态之后,会到as上进行初次注册,这时接收终端是可用的。另外,在接收终端与应用服务器之间进行初次注册之后,需要每隔一段时间向应用服务器进行一次刷新注册,以告知应用服务器自身当前是可达的,所以短信网关可以通过接收终端在as上的初次注册与刷新注册了解接收终端可达的信息。

s304、短信网关获取针对该接收终端待重投短消息所存储的失败投递记录。

当短信网关根据接收终端在as上的注册了解到该接收终端可达时,短信网关可以获取针对该接收终端待重投短消息所存储的失败投递记录。具体的,若短信网关仅在外部存储器上存储了该接收终端的失败投递记录,或当前接收终端在as上的注册属于初次注册,则短信网关可以直接到该外部存储器获取失败投递记录。若当前接收终端在as上的注册时刷新注册,而且终端预先不仅在外部存储器上存储了失败投递记录,而且还在本地存储了失败投递记录,则短信网关可以在本地获取失败投递记录。短信网关在本地存储失败投递记录可以是在以下两种情况中的至少一种下进行的:

第一种,当短信网关将失败投递记录存储到外部存储器,诸如hlr/hss等的同时,短信网关还将失败投递记录存储到本地。毫无疑义的是,如果短信网关在接收终端注册之后获取的失败投递记录是通过这种方式存储到本地的,则接收终端在失败投递记录存储到本地之后应当没有进行过初次注册。

第二种,短信网关在生成失败投递记录之后,仅将该失败投递记录存储到了外部存储器上,但是在接收终端初次注册或刷新注册之后,短信网关从外部存储器上获取到针对该接收终端的失败投递记录之后,将会把获取到的失败投递记录存储一份到本地。

所以,当短信网关通过上述两种方式中的任意一种将失败投递记录存储到本地之后,在接收终端到as上完成了刷新注册后,短信网关都可以从本地获取失败投递记录。

s306、短信网关根据失败投递记录触发短消息中心提醒。

短信网关获取到失败投递记录之后,就会根据该失败投递记录触发短消息中心提醒。下面结合图4对本实施例中短信网关触发短消息中心提醒的过程进行介绍:

s402、短信网关向hlr/hss发送map-ready-for-sm消息。

map-ready-for-sm是map定义的有关短消息业务的消息,其通常由短信网关在接收终端可以接收短消息时发送给hlr。当hlr/hss接收到短信网关发送的map-ready-for-sm消息后,通常还会向短信网关反馈一个对应的响应消息——“map-ready-for-sm-rsp”。

s404、hlr/hss向短消息中心发送map-alert-service-center消息。

map-alert-service-center即短消息中心提醒消息,其实质是用于告知短消息中心接收终端当前可达,可以安排对该接收终端进行待重投短消息的重新投递。当短消息中心接收到map-alert-service-center消息,也会向hlr/hss发送“map-alert-service-center-rsp”作为响应。

在本实施例中,短信网关在短消息投递失败之后,生成针对该短消息的失败投递记录,并将该失败投递记录进行存储,当其通过对应接收终端在应用服务器上的注册了解到该接收终端可达时,可以获取失败投递记录,并根据失败投递记录触发对短消息中心的提醒,告知短消息中心安排对待重投短消息的重新投递。由于本实施例中短信网关不用通过向hlr/hss进行订阅即可从应用服务器上直接了解到接收终端可达的相关信息,所以不用要求hlr/hss支持可达性订阅,降低了对hlr/hss的要求。更重要的是,本实施例中短信网关了解接收终端可达的方式更简单,不需要hlr/hss与mme相互配合即可实现,降低了对系统处理资源及通信资源的要求。

实施例二:

为了使本发明中短消息中心提醒方法的优点与细节更加清楚,本实施例在实施例一的基础上继续对短消息中心提醒方法进行介绍,请参见图5:

s502、短信网关在短消息投递失败之后存储针对该短消息的失败投递记录。

在本实施例中,短信网关可以是ip-sm-gw,即网际协议短信网关。短信网关可以将失败投递记录同时存储到本地与外部存储器上。假定外部存储器为hlr/hss上的存储器,下面对短信网关将失败投递记录存储到hlr/hss的过程进行介绍:

由于短信网关会向hlr/hss发送pur(profileupdaterequest,配置文件更新请求),所以,在本实施例中,短信网关和hlr/hss预先约定在pur中设置一个delivery-fail标记,即失败标识,用以短信网关通知hlr/hss某一短消息投递失败了。在后续过程中,当短信网关需要获取失败投递记录的时候,hlr/hss可以直接将delivery-fail标记携带在用户数据记录中返回给短信网关。

当然,由于在短消息投递后,短信网关会向hlr/hss发送map-report-sm-delivery-status消息,即短消息投递状态报告。当短消息投递失败之后,在短消息投递状态报告中也包含有短消息投递失败的相关信息,所以,短信网关也可以通过向hlr/hss发送短消息投递状态报告,以将失败投递记录存储到hlr/hss上。在本实施例当中,短信网关既会向hlr/hss发送携带失败标识的pur,又会发送短消息投递状态报告。

s504、当监测到待重投短消息对应的接收终端在as上注册时,短信网关获取失败投递记录。

当短信网关确定接收终端在应用服务器as上进行注册后,短信网关可以获取预先存储的失败投递记录。如果接收终端进行的是初次注册,则短信网关从hlr/hss等外部存储位置上获取失败投递记录,并将获取到的失败投递记录存储到本地,以防当前的短信重投不成功,后续接收终端进行刷新注册的时候可以直接从本地获得失败投递记录,从而节省获得失败投递记录的时间。

如果接收终端在应用服务器上进行的是刷新注册,则因为本实施例中短信网关之前在本地存储了失败投递记录,所以,短信网关可以直接从本地获取到失败投递记录。

s506、短信网关根据失败投递记录触发短消息中心提醒。

短信网关根据失败投递记录触发短消息中心提醒的过程在实施例一中已经进行了比较详细的介绍,这里不再阐述。

s508、短信网关判断待重投短消息是否投递成功。

当短消息中心控制短信网关对待重投短消息进行再次投递之后,只会有这样两种结果,一种是该待重投短消息投递成功了,另一种自然是待重投短消息的重新投递失败了。若判断结果为是,则执行s510,否则需要继续对待重投短消息进行投递,因此转至s504。

s510、短信网关清除针对该待重投短消息的失败投递记录。

由于短信网关在接收终端注册的时候就一定会获取失败投递记录进行对应失败短消息的重新投递,所以为了避免原本投递失败的短消息重投成功之后短信网关还会继续进行短信投递,给接收用户造成不佳的用户体验,浪费通信资源,本实施例中,当待重投短消息的重投成功之后,短信网关将会清除针对该短消息的失败投递记录。应当明白的是,短信网关应当清除包括本地的和外部存储器的所有存储位置上的失败投递记录。

本实施例中提供的短消息中心提醒方法,可以通过向hlr/hss发送携带失败标识的配置文件更新请求从而将针对投递失败的短消息的失败投递记录存储到hlr/hss上,利用hlr/hss等外部存储器不会因为接收终端状态的变化而清除失败投递记录的优点,让短信网关即使在接收终端初次注册后也能获得针对该接收终端待重投短消息的失败投递记录,从而对失败短消息进行重投。另外本实施例提供的短消息中心提醒方法还会在失败短消息的重投成功之后,删除本地与外部存储器上存储的这对该短消息的失败投递记录,避免短信网关一直对已经投递成功的短消息进行重复投递,浪费通信资源,降低用户体验。

实施例三:

本实施例结合具体的示例对短消息中心提醒进行进一步介绍,本实施例中假定短信网关为ip-sm-gw,由于ip-sm-gw可以作为独立网元进行部署,也可以和其他逻辑网元部署在一起。在本实施例中,ip-sm-gw部署在应用服务器上,所以,接收终端向应用服务器注册也就相当于向ip-sm-gw进行注册。值得注意的是这里所说的“相当于”实质是站在物理实体的角度上说的,是省略应用服务器这一逻辑网元与ip-sm-gw这一逻辑网关内部交互等到的,并不是完全等同。

下面将分失败投递记录的存储、初次注册时的短消息中心提醒以及刷新注册时的短消息中心提醒三个过程进行阐述,下面请先参见图6所示出的存储失败投递记录的一种交互图:

s601、ip-sm-gw向hlr/hss发送短消息投递状态报告;

s602、ip-sm-gw在本地保存失败投递记录;

s603、ip-sm-gw向hlr/hss发送pur消息;

s604、hlr/hss向ip-sm-gw发送pua消息。

在本实施例中,ip-sm-gw向hlr/hss发送pur消息中携带有delivery-fail标记,其可以向hlr/hss指示短信投递失败。当然,hlr/hss从短消息投递状态报告中也可以了解到短消息的投递结果。ip-sm-gw之所以会在hlr/hss能够通过短消息投递状态报告中了解短消息投递结果的情况下还向其发送携带失败标识的pur消息,这主要是因为短消息投递状态报告是现有通信协议中规定的,无论短消息的投递结果成功与否ip-sm-gw都会向hlr/hss发送的。而在本实施例中,后续ip-sm-gw获取失败投递记录的时候,需要了解的只是投递失败了的短消息是哪些,并不关心投递成功的短消息。所以,如果ip-sm-gw仅向hlr/hss发送短消息投递状态报告,则hlr/hss可能还需要根据接收的消息进行筛选才能向ip-sm-gw提供失败投递记录,因此,为了避免hlr/hss根据短消息投递状态报告进行筛选,本实施例中ip-sm-gw会在短消息投递失败之后向hlr/hss发送携带有失败标识的pur消息。

应当理解的是,s601、s602、s603这三个过程并没有严格的时序限制,短信网关可以根据自己的实际需求选择执行顺序。由于hlr/hss向ip-sm-gw发送的pua消息是对ip-sm-gw发送的pur消息的响应,所以,s604一定是在s603之后的。

请参见图7示出的ip-sm-gw根据接收终端在as上的初次注册进行短消息中心提醒的一种交互图:

s701、接收终端向as发起初始注册。

由于as与ip-sm-gw部署在一起,也即ip-sm-gw被部署到应用服务器上,所以ip-sm-gw的部分功能可以由应用服务器承担。所以当接收终端向as发起注册的时候,ip-sm-gw可以立即获知到该信息。

s702、ip-sm-gw向hlr/hss发送用户数据请求udr。

s703、hlr/hss向ip-sm-gw发送用户数据响应uda。

udr(userdatarequest,用户数据请求)能够让hlr/hss将存储的用户数据发送给ip-sm-gw,在hlr/hss向ip-sm-gw发送的uda当中,包括有ip-sm-gw预先发送给hlr/hss的delivery-fail标记。

s704、ip-sm-gw向hlr/hss发送订阅通知请求snr。

s705、hlr/hss向ip-sm-gw发送订阅通知请求sna。

发送snr(subscribenotificationrequest,订阅通知请求)与接收sna(subscribenotificationanswer,订阅通知响应)的过程是现有终端在应用服务器上注册所需要经历的过程,并不是本实施例中实现短消息中心提醒所必须的过程。

s706、ip-sm-gw向接收终端发送200ok消息。

当ip-sm-gw接收到hlr/hss发送的用户数据响应sna之后,表征接收终端在应用服务器上的初始注册已经成功,所以ip-sm-gw会向接收终端侧发送一个200ok消息作为接收终端发送注册请求的响应。

s707、ip-sm-gw向hlr/hss发送map-ready-for-sm消息。

s708、hlr/hss向ip-sm-gw发送map-ready-for-sm-rsp消息。

ip-sm-gw向hlr/hss发送map-ready-for-sm消息是为了通知hlr/hss对短消息中心进行map-alert-service-center提醒,而map-ready-for-sm-rsp则是hlr/hss在接收到map-ready-for-sm之后对ip-sm-gw的响应消息。

s709、hlr/hss向短消息中心发送map-alert-service-center消息。

s710、短消息中心向hlr/hss发送map-alert-service-center-rsp消息。

hlr/hss向短消息中心发送的map-alert-service-center消息可以用于提醒短消息中心当前接收终端可达,可以重新对之前投递失败的短消息进行重新投递。而短消息中心接收到map-alert-service-center之后,会向hlr/hss反馈map-alert-service-center-rsp消息作为响应。

下面假定短消息中心重新安排对原本投递失败的短消息进行重新投递后投递结果为成功。则ip-sm-gw还会删除针对该短消息的失败投递记录:

s711、ip-sm-gw删除本地存储的失败投递记录。

s712、ip-sm-gw向hlr/hss发送不携带失败标识的pur消息。

s713、hlr/hss向ip-sm-gw发送pua消息。

显然,在图7当中,s712与s713是为了清除存储在hlr/hss上的失败投递记录,而s711则是为了清除存储在ip-sm-gw本地的失败投递记录。但其实ip-sm-gw可以先清除本地存储的失败投递记录,也可以先清除存储在hlr/hss上的失败投递记录,所以,s711可以在s712之前,也可以在s713之后。

请参见图8示出的ip-sm-gw根据接收终端在as上的初次注册进行短消息中心提醒的一种交互图:

s801、接收终端向as发起刷新注册。

s802、as向接收终端返回200ok消息。

由于刷新注册并不会使ip-sm-gw清除本地存储的该接收终端的数据,所以在本实施例中,ip-sm-gw不需要在刷新注册后向hlr/hss获取用户数据,as在接收到刷新注册之后,可以直接向接收终端返回200ok消息进行响应。

s803、ip-sm-gw向hlr/hss发送map-ready-for-sm消息。

s804、hlr/hss向ip-sm-gw发送map-ready-for-sm-rsp消息。

ip-sm-gw根据本地存储的失败投递记录向hlr/hss发送map-ready-for-sm消息是为了通知hlr/hss对短消息中心进行map-alert-service-center提醒,而map-ready-for-sm-rsp则是hlr/hss在接收到map-ready-for-sm之后对ip-sm-gw的响应消息。

s805、hlr/hss向短消息中心发送map-alert-service-center消息。

s806、短消息中心向hlr/hss发送map-alert-service-center-rsp消息。

hlr/hss向短消息中心发送的map-alert-service-center消息可以用于提醒短消息中心当前接收终端可达,可以重新对之前投递失败的短消息进行重新投递。而短消息中心接收到map-alert-service-center之后,会向hlr/hss反馈map-alert-service-center-rsp消息作为响应。

本实施例中,若短消息中心安排ip-sm-gw对失败短消息进行重新投递,并投递成功之后,ip-sm-gw也需要清除存储在本地和hlr/hss上的失败投递记录,其过程与初次注册后的过程相同,这里不再赘述。若投递失败,则继续等待接收终端在as上的刷新注册或者初次注册。

本发明实施例提供的短消息中心提醒方法,ip-sm-gw与应用服务器部署在一起,所以二者的部分功能可以共同承担,当接收终端向应用服务器注册的时候,ip-sm-gw能够快速获取到注册消息,ip-sm-gw能够理解了解到,相对于向hlr/hss进行接收终端可达性订阅的做法,能够更快速地获取接收终端可达的时间,降低了对系统处理资源与通信资源的占用,有利于资源的优化配置。

实施例四:

本实施例提供一种短信网关,请参见图9:短信网关90包括记录模块902、确定模块904、获取模块906以及提醒模块908。

假定发送终端向接收终端发送了一条内容为“你周六有时间吗?”的短消息,则当发送终端选择发送之后,该短消息首先会被传递到短消息中心,由短消息中心安排接收终端侧的短信网关90对该短消息进行投递。如果短信网关90投递短消息的时候,接收终端处于关机或者因通信质量极差而无法接通的状态,则短信网关90的投递就会失败。在通常情况下,一条短消息投递失败之后意味着该短消息需要被重新投递。

所以本实施例中的记录模块902会在投递失败的时候记录下针对该失败短消息,也即待重投短消息的失败投递记录,以便在对应接收终端可达的时候,再次进行该待重投短消息的投递。记录模块902存储的失败投递记录可表征是哪条短消息待重投,而不用记录失败短消息的具体内容是什么,因为失败短消息的具体内容由短消息中心记录。

虽然失败投递记录是提醒模块908在触发短消息中心提醒时所需要的,也即,失败投递记录是短信网关90本身所需要的,因此理论上,失败投递记录应当被存储在短信网关90上,但由于一个终端从关机状态进入开机状态之后,会到as上进行一次注册,该注册过程被称为初次注册,终端初次注册的时候,短信网关90本地存储的针对该终端的数据将会被清除掉。而应当理解的是,在待重投短消息重新投递成功之前,针对该待重投短消息的失败投递记录都是必要的,所以记录模块902不能仅仅将失败投递记录存储在本地,其至少应当将该失败投递记录存储在一个不会随意被清除的地方。所以,本实施例中,记录模块902会将失败投递记录存储一份到hlr/hss上。不过应当理解的是,除了hlr/hss,记录模块902还可以将失败投递记录存储到其他外部存储器上,只要该存储位置中的数据不会随着终端的开关机而被删除即可。

另外,由于需要使用失败投递记录的短信网关90本身,而只要接收终端暂时不到应用服务器上进行初次注册,则短信网关90并不会将本地存储的针对该接收终端的数据进行清除,所以,在本实施例中,记录模块902还可以将失败投递记录存储一份在短信网关90本地,这样,只要接收终端不进行初次注册,在需要获取失败投递记录的时候,获取模块906就可以从本地获取到,相对于在任何情况下都从外部存储位置获取失败投递记录的做法,能够很好的避免从外部存储位置获取失败投递记录需要花费大量时间的问题。

应当理解的是,短信网关90对待重投短消息进行重新投递的时机并不是自己或短消息中心随机确定的,而是由接收终端确定的。只有当接收终端可达时,提醒模块908才会触发短消息中心提醒,通知短消息中心重新安排对失败短消息的投递。本实施例中,确定模块904可以直接从as(applicationserver,应用服务器)获取接收终端可达的信息,取代向hlr/hss进行接收终端可达性订阅的做法。当接收终端从关机状态进入开机状态之后,会到as上进行初次注册,这时接收终端是可用的。另外,在接收终端与应用服务器之间进行初次注册之后,需要每隔一段时间向应用服务器进行一次刷新注册,以告知应用服务器自身当前是可达的,所以确定模块904可以通过接收终端在as上的初次注册于刷新注册了解接收终端可达的信息。

当确定模块904根据接收终端在as上的注册了解到该接收终端可达时,获取模块906可以获取针对该接收终端待重投短消息所存储的失败投递记录。具体的,若记录模块902仅在外部存储器上存储了该接收终端的失败投递记录,或当前接收终端在as上的注册属于初次注册,则获取模块906可以直接到该外部存储器获取失败投递记录。若当前接收终端在as上的注册时刷新注册,而且终端预先不仅在外部存储器上存储了失败投递记录,而且还在本地存储了失败投递记录,则获取模块906可以在本地获取失败投递记录。记录模块902在本地存储失败投递记录可以是在这两种情况下进行的:

第一种,当记录模块902将失败投递记录存储到外部存储器,诸如hlr/hss等的同时,还将失败投递记录存储到本地。毫无疑义的是,如果获取模块906在接收终端注册之后获取的失败投递记录是通过这种方式存储到本地的,则接收终端在失败投递记录存储到本地之后应当没有进行过初次注册。

第二种,记录模块902在生成失败投递记录之后,仅将该失败投递记录存储到了外部存储器上,但是在接收终端初次注册或刷新注册之后,获取模块906从外部存储器上获取到针对该接收终端的失败投递记录之后,记录模块902将会把获取到的失败投递记录存储一份到本地。

所以,当记录模块902通过上述两种方式中的至少一种将失败投递记录存储到本地之后,在确定模块904了解到接收终端到as上完成了刷新注册后,获取模块906都可以从本地获取失败投递记录。

获取模块906获取到失败投递记录之后,就会根据该失败投递记录触发短消息中心提醒。提醒模块908可以通过向hlr/hss发送map-ready-for-sm触发短消息中心提醒,map-ready-for-sm是map定义的有关短消息业务的消息,其通常由短信网关在接收终端可以接收短消息时发送给hlr。当hlr/hss接收到提醒模块908发送的map-ready-for-sm消息后,通常还会向提醒模块908反馈一个对应的响应消息——“map-ready-for-sm-rsp”。

hlr/hss接收到map-ready-for-sm后会向短消息中心发送短消息中心提醒消息,即map-alert-service-center消息,用于告知短消息中心接收终端当前可达,可以安排对该接收终端进行待重投短消息的重新投递。当短消息中心接收到map-alert-service-center消息,也会向hlr/hss发送“map-alert-service-center-rsp”作为响应。

在本实施例中,短信网关在短消息投递失败之后,生成针对该短消息的失败投递记录,并将该失败投递记录进行存储,当其通过对应接收终端在应用服务器上的注册了解到该接收终端可达时,可以获取失败投递记录,并根据失败投递记录触发对短消息中心的提醒,告知短消息中心安排对待重投短消息的重新投递。由于本实施例中短信网关不用通过向hlr/hss进行订阅即可从应用服务器上直接了解到接收终端可达的相关信息,所以不用要求hlr/hss支持可达性订阅,降低了对hlr/hss的要求。更重要的是,本实施例中短信网关了解接收终端可达的方式更简单,不需要hlr/hss与mme相互配合即可实现,降低了对系统处理资源及通信资源的要求。

实施例五:

为了使本发明中短消息中心提醒方法的优点与细节更加清楚,本实施例在实施例四的基础上继续对短信网关进行介绍,请继续参照图10,短信网关90还包括清除模块910。

记录模块902在短消息投递失败之后存储针对该短消息的失败投递记录。在本实施例中,短信网关90可以是ip-sm-gw,即网际协议短信网关。记录模块902可以将失败投递记录同时存储到本地与外部存储器上。假定外部存储器为hlr/hss上的存储器,下面对记录模块902将失败投递记录存储到hlr/hss的过程进行介绍:

由于短信网关90会向hlr/hss发送pur(profileupdaterequest,配置文件更新请求),所以,在本实施例中,记录模块902和hlr/hss预先约定在pur中设置一个delivery-fail标记,即失败标识,用以记录模块902通知hlr/hss某一短消息投递失败了。在后续过程中,当获取模块906需要获取失败投递记录的时候,hlr/hss可以直接将delivery-fail标记携带在用户数据记录中返回给获取模块906。

当然,由于在短消息投递后,短信网关90会向hlr/hss发送map-report-sm-delivery-status消息,即短消息投递状态报告。当短消息投递失败之后,在短消息投递状态报告中也包含有短消息投递失败的相关信息,所以,记录模块902也可以通过向hlr/hss发送短消息投递状态报告,以将失败投递记录存储到hlr/hss上。在本实施例当中,短信网关90既会向hlr/hss发送携带失败标识的pur,又会发送短消息投递状态报告。

当确定接收终端在应用服务器as上进行注册后,获取模块906可以获取预先存储的失败投递记录。如果接收终端进行的是初次注册,则获取模块906从hlr/hss等外部存储位置上获取失败投递记录,并将获取到的失败投递记录存储到本地,以防当前的短信重投不成功,后续接收终端进行刷新注册的时候可以直接从本地获得失败投递记录,从而节省获得失败投递记录的时间。

如果接收终端在应用服务器上进行的是刷新注册,则因为本实施例中记录模块902之前在本地存储了失败投递记录,所以,获取模块906可以直接从本地获取到失败投递记录。

提醒模块908根据失败投递记录触发短消息中心提醒的过程在实施例一中已经进行了比较详细的介绍,这里不再阐述。

当短消息中心控制短信网关90对待重投短消息进行再次投递之后,只会有这样两种结果,一种是该待重投短消息投递成功了,另一种自然是待重投短消息的重新投递失败了。若待重投短消息投递成功,则清除模块910需要清除针对该待重投短消息的失败投递记录。

由于获取模块906在接收终端到应用服务器注册的时候就一定会获取失败投递记录,并通知提醒模块908进行对应失败短消息的重新投递,所以为了避免原本投递失败的短消息重投成功之后短信网关90还会继续进行短信投递,给接收用户造成不佳的用户体验,浪费通信资源,本实施例中,当待重投短消息的重投成功之后,清除模块910将会清除针对该短消息的失败投递记录。应当明白的是,清除模块910应当清除包括本地的和外部存储器的所有存储位置上的失败投递记录。

本实施例中提供的短信网关,可以通过向hlr/hss发送携带失败标识的配置文件更新请求从而将针对投递失败的短消息的失败投递记录存储到hlr/hss上,利用hlr/hss等外部存储器不会因为接收终端状态的变化而清除失败投递记录的优点,让短信网关即使在接收终端初次注册后也能获得针对该接收终端待重投短消息的失败投递记录,从而对失败短消息进行重投。另外本实施例提供的短消息中心提醒方法还会在失败短消息的重投成功之后,删除本地与外部存储器上存储的这对该短消息的失败投递记录,避免短信网关一直对已经投递成功的短消息进行重复投递,浪费通信资源,降低用户体验。

实施例六:

前述各实施例中的短信网关可以作为一个单独的网元部署在一物理实体上,也可以和其他逻辑网元共享一物理实体。本实施例中将短信网关部署在服务器上,下面结合图11对本发明各实施例中的短信网关的硬件结构进行介绍:

服务器100至少包括输入输出(io)总线110、处理器140、存储器130、内存120和通信装置150。

其中,输入输出(io)总线110分别与自身所属的服务器的其它部件(处理器140、存储器130、内存120和通信装置150)连接,并且为其它部件提供传送线路。

内存120中可以存储用于实现短消息中心提醒方法的计算机程序,当服务器100需要执行前述短消息中心提醒方法时,处理器140从内存120中读取出代码进行编译后控制各个部件相互配合,实现短消息中心提醒方法中的各个流程。

当短信网关需要将失败投递记录存储到本地的时候,存储器130可以在处理器140的控制下存储失败投递记录。

处理器140通常控制自身所属的服务器的总体操作。例如,处理器140执行计算和确认等操作。其中,处理器140可以是中央处理器(cpu)。

通信装置150,通常包括一个或多个组件,其允许自身所属的服务器与无线通信系统或网络之间的无线电通信。当短信网关需要与应用服务器或者hlr/hss交互时,通信装置150则在处理器140的控制下承担了相应的通信任务。

实施例四与实施例五提供的短信网关中的记录模块、确定模块、获取模块、清除模块的功能可以由处理器140与存储器130、通信装置150相互配合实现。提醒模块的功能可以由处理器与通信装置二者配合实现。在短消息投递失败之后,处理器140可以在本地存储器130中存储失败投递记录,同时控制通信装置150将该失败投递记录存储到外部存储器中,例如存储到hlr/hss上。当接收终端在应用服务器as上进行初次注册或刷新注册的时候,通信装置150通过与应用服务器的交互,可以了解到该接收终端可用。若接收终端的注册属于初次注册,则处理器140可以控制通信装置150向hlr/hss等外部存储器发送请求消息,获取之前存储的失败存储记录。获取到失败投递记录之后,处理器140控制存储器130将获取到的失败投递记录进行存储。并根据该失败投递记录控制通信装置150与hlr/hss进行交互,从而让hlr/hss向短消息中心发送map-alert-service-center消息。若接收终端的注册属于刷新注册,则处理器140可以直接从本地存储器130中获取失败投递记录,并通知通信装置150与hlr/hss交互,让hlr/hss向短消息中心发送map-alert-service-center消息完成短消息中心提醒。

另外,前述实施例中的短信网关也可以和应用服务器部署在同一服务器上,在这种情况下,接收终端与应用服务器的通信装置交互实现注册,实质上也就是在与短信网关交互,所以短信网关能够直接获取接收终端可达的信息,节约可达性获取时间,降低资源浪费。

显然,本领域的技术人员应该明白,上述本发明实施例的各模块或各步骤可以用通用的计算装置来实现,它们可以集中在单个的计算装置上,或者分布在多个计算装置所组成的网络上,可选地,它们可以用计算装置可执行的程序代码来实现,从而,可以将它们存储在计算机存储介质(rom/ram、磁碟、光盘)中由计算装置来执行,并且在某些情况下,可以以不同于此处的顺序执行所示出或描述的步骤,或者将它们分别制作成各个集成电路模块,或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。所以,本发明不限制于任何特定的硬件和软件结合。

以上内容是结合具体的实施方式对本发明实施例所作的进一步详细说明,不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的普通技术人员来说,在不脱离本发明构思的前提下,还可以做出若干简单推演或替换,都应当视为属于本发明的保护范围。

当前第1页1 2 
网友询问留言 已有0条留言
  • 还没有人留言评论。精彩留言会获得点赞!
1