背景技术
在现有技术中,与MTC(MachineTypeCommunication,机器类通信)DeviceTrigger(设备触发)相关的需求包括:
网络应能够基于MTCServer(服务器)发送的触发指示触发MTC终端发起与MTCServer的通信。
MTC终端应能从网络接收触发指示并建立与MTCServer间的通信。可能的情况包括:
当MTC终端离线(offline)时接收触发指示。
当MTC终端在线(online)但没有建立数据连接时接收触发指示。
当MTC终端在线(online)并已建立数据连接时接收触发指示。
这里需要说明的是,在现有技术中,对应于3GPP(ThirdGenerationPartnershipProject,第三代移动通信伙伴计划)网络系统,数据连接是指终端在3GPP网络中建立的PDP(PacketDataProtocol,分组数据协议)上下文或PDN(PacketDataNetwork,分组数据网络)连接。
而在现有的技术方案中,还提出支持MTCDeviceTrigger特性的HPLMN(HomePublicLandMobileNetwork,本地公用陆地移动网络)提供的用于传输Trigger消息到本PLMN(PublicLandMobileNetwork,公用陆地移动网络)的接口须满足以下要求。
-shallallowforprovidingavalidityorlifetimethatindicateshowlongthenetworkshouldstorethetriggerrequestwhenitcannotbedeliveredtotheUE,e.g.whentheUEisnotreachableorwhenloadcontrolpreventsimmediatedelivery
即,必须考虑提供生命周期指示网络在不能传递Trigger到UE时(例如UE不可达或者负载控制而导致不能立刻传送时),网络应该保存该trigger多长时间。
另外,MTCDeviceTrigger特性需要满足以下要求。
-Thenetworkshallbeabletoreportthesuccessorfailureofthetrigger(e.g.duetonetworkcongestion)totheMTCserver,ifsorequestedbytheMTCServer.
即,如果MTCServer请求了报告Trigger消息是否成功传输(例如网络拥塞而导致传输失败),则网络需要向MTCServer报告相关信息。
另一方面,为了实现触发MTCDevice的需求,现有技术中提出了使用NAS(Non-Access-Stratum,非接入层)信令来触发MTCDevice的方法,该方法适用于成功attached(附着)的UE。
具体如图1所示,为现有技术中通过NAS信令触发MTCDevice的方法的流程示意图,具体包括以下步骤:
步骤S101、MTCServer希望联系UE时,向HSS(HomeSubscriberServer,归属用户服务器)/HLR(HomeLocationRegister,归属位置寄存器)发送Trigger消息。
图1中所示的为UEapplicationtriggerrequest(UE应用触发请求)。
步骤S102、HSS/HLR先验证该trigger请求;再将trigger消息中的UE的标志转换为3GPP网络能够识别的标志,例如IMSI(InternationalMobileSubscriberIdentificationNumber,国际移动用户识别码);然后将该请求保存在数据库;最后选择当前正在服务UE的MME(MobilityManagementEntity,移动性管理实体)或者SGSN(ServingGPRSSupportNode,GPRS服务节点,其中,GPRS,GeneralPacketRadioService,通用分组无线业务),并将trigger消息发送给servingMME/SGSN,MME/SGSN收到后需要向HSS/HLR返回确认;MME收到Trigger消息后,保存该Trigger。
步骤S103、MME/SGSN将trigger消息封装在NAS信令中,传给UE。
如果trigger消息不紧急,则可以在下一次UE和网络进行NAS信令交互的时候传递;如果trigger消息紧急,则网络应该立刻寻呼UE,并传递该trigger消息。
步骤S104、UE收到Trigger信息后,UE使用计数器来判断是否收到重复的Trigger;UE向MME/SGSN发送NAS信令来确认;然后建立与MTCServer的通信。
步骤S105、网络收到UE的确认后,将保存的Trigger删除,并向HSS/HLR返回Trigger已经传递的确认。
在此方法中,HSS/HLR也可以是一个能够实现上述功能的中间节点,例如MTC-IWF(Inter-workingFunction,互动功能单元)。
另一方面,现有技术中的SMS(ShortMessageService,短信业务)机制存在确认机制,MME/SGSN只需转发UE上报的投递报告。
具体如图2所示,为现有技术中SMS机制中的确认机制的流程示意图,在该图中所示的步骤S211至步骤S212,MME收到UE上传的投递报告后,仅仅转发至GMSC(GatewayMobileSwitchingCenter,网关移动交换中心),然后由GMSC来控制是否重传短消息。
在实现本发明的过程中,发明人发现现有技术中至少存在以下问题:
当网络收到某个UE的多个Trigger时(多个MTCServer发出的Trigger和一个MTCServer发出多个Trigger的场景),如果存在Trigger消息投递不成功,则网络不能区分当前哪些成功投递,哪些不成功;例如:
根据现有技术,当UE处于连接态,网络使用DOWNLINKGENERICNASTRANSPORT消息封装一条Trigger消息,传递到UE后,又收到一条新的来自相同或者不同MTCServer的Trigger消息时,此时UE不能根据计数器来判断收到重复的Trigger消息,因为这两条Trigger的内容可能是不同的,例如可能是触发建立不同的PDN连接,因此,如果UE只收到一条Trigger消息,并使用DOWNLINKGENERICNASTRANSPORT消息封装了确认消息返回给网络时,网络不知道该确认是针对哪条的Trigger消息的。
具体实施方式
如背景技术所述,现有的技术标准中提出了MTCDeviceTriggering的特性,MTCServer能够通过MTCDeviceTrigger消息控制终端设备接入Server,而为了让MTCServer知道MTCDeviceTrigger消息是否传递成功,网络需要向MTCServer报告DeviceTrigger消息是否传输成功的需求,但根据现有3GPP的SAE网络的架构,采用NAS信令来触发MTCDevice的方式下,在同时处理多个Trigger过程时,网络并不能区分相应的消息具体是针对哪个Trigger过程的,自然也就不能解决网络如何向MTCServer报告Trigger消息是否传输成功的问题。
为了克服这样的缺陷,本发明实施例提出了一种MTCDevice触发消息的投递确认方法,在采用NAS信令来触发MTCDevice的场景下,通过终端设备所反馈的特定的消息,来确认MTCDevice触发消息是否投递成功。
相应的技术方案中由具体的管理服务器作为判断主体,来确认MTCDevice触发消息是否投递成功。
在具体的实施场景中,这里所提及的管理服务器可以是MME或SGSN,具体物理实体类型的变化并不会影响本发明的保护范围。
如图3所示,为本发明实施例所提出的一种MTCDevice触发消息的投递确认方法的流程示意图,该方法具体包括以下步骤:
步骤S301、当管理服务器根据接收到的触发请求消息生成MTCDevice触发消息时,所述管理服务器为所述MTCDevice触发消息分配标识信息,并将所述MTCDevice触发消息与所述标识信息在本地绑定存储。
步骤S302、所述管理服务器向终端设备发送携带所述标识信息和所述MTCDevice触发消息的第一消息。
当所述管理服务器接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息时,执行步骤S303。
步骤S303、所述管理服务器判断所述第二消息中所携带的标识信息与本地绑定存储的所述标识信息是否一致。
在本发明实施例所提出的技术方案中,终端设备在对第一消息中的MTCDevice触发消息进行处理后,会将该第一消息中的标识信息与相应的确认消息一起携带在第二消息中反馈给管理设备,从而,管理服务器可以据此来识别确认消息到底是针对哪个MTCDevice触发消息的。
基于上述的处理思路,如果本步骤中的判断结果为一致,则执行步骤S304。
步骤S304、所述管理服务器确定所述第二消息中所携带的确认消息是对本地绑定存储的所述MTCDevice触发消息的确认消息,在本地删除绑定存储的所述MTCDevice触发消息与所述标识信息,并转发所述第二消息所携带的确认消息。
通过这样的处理,可以准确识别到针对相应的MTCDevice触发消息的确认消息,并将该确认消息上报,从而,确定MTCDevice触发消息传输成功。
在上述的处理过程中,如果步骤S303的判断结果为不一致,则表明当前所接收到的第二消息中的确认消息并不是对本地绑定存储的所述MTCDevice触发消息的确认消息,因此,并不会根据当前的第二消息对本地绑定存储的所述MTCDevice触发消息进行具体的处理,而是继续等待其他的第二消息,从而,使管理服务器能够区分确认消息所针对的是哪个MTCDevice触发消息,并进而确定哪个MTCDevice触发消息的投递成功。
需要进一步指出的是,现有技术中所应用的类似短消息的投递报告机制不适合使用NAS信令进行Trigger消息传递的机制,因为,此架构中没有类似GMSC的节点,同时,Trigger机制具有时效性的特点,需要考虑Trigger消息的生命周期,显然,现有的技术方案并没有考虑这样的问题。
为了克服这样的缺陷,本发明实施例所提出的技术方案中进一步引入了生命周期的处理机制,相应的处理过程需要进行调整如下。
在步骤S301中,为了体现MTCDevice触发消息的生命周期特性,所述管理服务器处理将所述MTCDevice触发消息与所述标识信息在本地绑定存储,还在本地存储了所述MTCDevice触发消息的生命周期。
步骤S302的处理保持不变,而在此之后,需要根据生命周期是否到期来进行相应的处理,具体分为以下三种情况。
情况一、在所述生命周期到达之前,所述管理服务器接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息。
在此种情况下,执行步骤S303。
如果判断结果为一致,所述管理服务器确定所述第二消息中所携带的确认消息是对本地绑定存储的所述MTCDevice触发消息的确认消息,在本地删除绑定存储的所述MTCDevice触发消息与所述标识信息,以及所述MTCDevice触发消息的生命周期,并转发所述第二消息所携带的确认消息。
如果判断结果为不一致,则表明当前所接收到的第二消息中的确认消息并不是对本地绑定存储的所述MTCDevice触发消息的确认消息,因此,并不会根据当前的第二消息对本地绑定存储的所述MTCDevice触发消息进行具体的处理,而是继续等待其他的第二消息,从而,使管理服务器能够区分确认消息所针对的是哪个MTCDevice触发消息,并进而确定哪个MTCDevice触发消息的投递成功。
情况二、所述管理服务器在所述生命周期到达之前,没有接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息。
在本情况下,在完整的生命周期内,管理服务器没有接收到任何的符合要求的第二消息,自然,也就不可能接收到对本地绑定存储的所述MTCDevice触发消息的确认消息,因此,在该MTCDevice触发消息的生命周期内,该MTCDevice触发消息没有投递成功,所述管理服务器在本地删除绑定存储的所述MTCDevice触发消息与所述标识信息,以及所述MTCDevice触发消息的生命周期,并上报所述MTCDevice触发消息触发失败。
情况三、所述管理服务器在所述生命周期到达之前,没有接收到携带对本地绑定存储的所述MTCDevice触发消息的确认消息的第二消息。
此种情况相当于情况一种判断结果为不一致的情况的多次循环,即管理服务器在生命周期内虽然收到了第二消息,但其中携带的标识信息均不是本地绑定存储的标识信息,即当前所接收到的各第二消息中的确认消息并不是对本地绑定存储的所述MTCDevice触发消息的确认消息,因此,管理服务器确定在本地绑定存储的所述MTCDevice触发消息的完整生命周期内,均没有接收到对该MTCDevice触发消息的确认消息,因此,在该MTCDevice触发消息的生命周期内,该MTCDevice触发消息没有投递成功,所述管理服务器在本地删除绑定存储的所述MTCDevice触发消息与所述标识信息,以及所述MTCDevice触发消息的生命周期,并上报所述MTCDevice触发消息触发失败。
通过上述的三种情况的处理,不仅体现了MTCDevice触发消息的生命周期特性,而且基于这种特性,引入了鉴别MTCDevice触发消息触发失败的机制,可以及时上报触发失败的结果,避免无限制地等待投递成功的结果所带来的资源浪费和处理效率的降低。
另一方面,在现有技术方案中,由于网络拥塞等原因,MTCDevice触发消息无法及时发送给终端设备,管理服务器也不会采取其他的补救措施,只会一直等待接收相应的确认消息,而且,由于网络拥塞等原因,管理服务器还可能会出现没有收到终端设备返回的对相应MTCDevice触发消息的确认消息的情况,而这样的情况下,终端设备和管理服务器对于当前触发结果的理解自然会存在明显的区别,一方面,终端设备在触发成功后迟迟无法开展相对应的后续业务,而另一方面,管理服务器则会一直等待接收相应的确认消息,这样的结果导致了相应的处理过程不能正常继续,且没有相应的机制对投递成功率进行保证,影响MTCDevice触发消息的传输过程的可靠性。
为了克服这样的缺陷,本发明实施例所提出的技术方案中进一步引入了基于计时器的重传机制,相应的处理过程需要进行调整如下。
步骤S301的处理保持不变。
在步骤S302中,所述管理服务器向终端设备发送携带所述标识信息和所述MTCDevice触发消息的第一消息的过程中,所述管理服务器还启动了与所述标识信息相对应的计时器。
而在此之后,需要根据计时器是否超时来进行相应的处理,具体分为以下三种情况。
情况一、所述管理服务器在所述计时器超时之前,接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息。
在此种情况下,执行步骤S303。
如果判断结果为一致,所述管理服务器确定所述第二消息中所携带的确认消息是对本地绑定存储的所述MTCDevice触发消息的确认消息,则停止与所述标识信息相对应的计时器,在本地删除绑定存储的所述MTCDevice触发消息与所述标识信息,并转发所述第二消息所携带的确认消息。
如果判断结果为不一致,则表明当前所接收到的第二消息中的确认消息并不是对本地绑定存储的所述MTCDevice触发消息的确认消息,因此,并不会根据当前的第二消息对本地绑定存储的所述MTCDevice触发消息进行具体的处理,而是继续等待其他的第二消息,从而,使管理服务器能够区分确认消息所针对的是哪个MTCDevice触发消息,并进而确定哪个MTCDevice触发消息的投递成功。
情况二、所述管理服务器在所述计时器超时之前,没有接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息。
在本情况下,在计时器当前的完整的计时周期内,管理服务器没有接收到任何的符合要求的第二消息,自然,也就不可能接收到对本地绑定存储的所述MTCDevice触发消息的确认消息,因此,在该MTCDevice触发消息的计时器当前的完整的计时周期内,该MTCDevice触发消息没有投递成功,从而,启动重传机制,所述管理服务器重新向终端设备发送携带所述标识信息和所述MTCDevice触发消息的第一消息,并重新启动与所述标识信息相对应的计时器。
情况三、所述管理服务器在所述计时器超时之前,没有接收到携带对本地绑定存储的所述MTCDevice触发消息的确认消息的第二消息。
此种情况相当于情况一种判断结果为不一致的情况的多次循环,即管理服务器在所述计时器的本次计时周期内虽然收到了符合要求的第二消息,但其中携带的标识信息均不是本地绑定存储的标识信息,即当前所接收到的各第二消息中的确认消息并不是对本地绑定存储的所述MTCDevice触发消息的确认消息,因此,管理服务器确定在本次计时周期内,均没有接收到对该MTCDevice触发消息的确认消息,因此,在该本次计时周期内,该MTCDevice触发消息没有投递成功,从而,启动重传机制,所述管理服务器重新向终端设备发送携带所述标识信息和所述MTCDevice触发消息的第一消息,并重新启动与所述标识信息相对应的计时器。
通过上述的三种情况的处理,引入了基于计时器的重传机制,管理服务器不会无限制地等待投递成功的结果,而是在计时器超时且没有接收到投递成功的结果的情况下,直接对MTCDevice触发消息进行了重传,尽量提高MTCDevice触发消息的投递成功率。
基于这样的处理即使由于网络拥塞等原因,导致MTCDevice触发消息无法及时送达或确认消息无法及时返回的情况,也可以通过重传进行补救,尽量保证MTCDevice触发消息能够投递成功。
为了实现更好的技术效果,本发明实施例所提出的技术方案还可以同时引入生命周期的处理机制和基于计时器的重传机制,在有限的生命周期中,尽可能通过重传机制提高MTCDevice触发消息的投递成功率。
基于这样的技术思路,进一步对前述的本发明实施例所提出的技术方案进行调整,如图4所示,为本发明实施例提出的一种同时引入生命周期的处理机制和基于计时器的重传机制的MTCDevice触发消息的投递确认方法的流程示意图,该方法具体包括以下步骤:
步骤S401、当管理服务器根据接收到的触发请求消息生成MTCDevice触发消息时,所述管理服务器为所述MTCDevice触发消息分配标识信息,将所述MTCDevice触发消息与所述标识信息在本地绑定存储,并在本地存储所述MTCDevice触发消息的生命周期。
步骤S402、所述管理服务器向终端设备发送携带所述标识信息和所述MTCDevice触发消息的第一消息,并启动与所述标识信息相对应的计时器。
其中,所述生命周期的时长大于或等于与所述标识信息相对应的计时器的计时周期的时长。
步骤S403、所述管理服务器判断在所述计时器超时之前,是否接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息。
如果判断结果为是,则执行步骤S404;
如果判断结果为否,则执行步骤S406。
其中,判断结果为否的情况包括两种:
情况一、在所述计时器超时之前,没有接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息。
情况二、通过后续步骤确定在所述计时器的本次计时周期内所接收到的所有第二消息中所携带的确认消息均不是对本地绑定存储的所述MTCDevice触发消息的确认消息。
步骤S404、所述管理服务器判断所述第二消息中所携带的标识信息与本地绑定存储的所述标识信息是否一致。
如果一致,则执行步骤S405;
如果不一致,则返回步骤S403。
在不一致的情况下,管理服务器认为当前接收到的这个第二消息没有对当前的计时器产生影响,因此,需要返回步骤S403,继续进行其他第二消息的接收。
尤其是当前如果存在对应不同标识信息的多个计时器,那么本步骤的判断显然可以避免携带不同标识信息的第二消息对于其他计时器的干扰,准确的对相应的标识信息所绑定的MTCDevice触发消息的投递过程进行监控。
步骤S405、所述管理服务器确定所述第二消息中所携带的确认消息是对本地绑定存储的所述MTCDevice触发消息的确认消息,所述管理服务器停止与所述标识信息相对应的计时器,在本地删除绑定存储的所述MTCDevice触发消息与所述标识信息,以及所述MTCDevice触发消息的生命周期,并转发所述第二消息所携带的确认消息。
步骤S406、所述管理服务器判断所述MTCDevice触发消息是否满足重传条件。
如果满足,返回执行步骤S402,即所述管理服务器重新向终端设备发送携带所述标识信息和所述MTCDevice触发消息的第一消息,并重新启动与所述标识信息相对应的计时器;
如果不满足,则执行步骤S407。
在具体的处理场景中,本步骤的判断处理过程具体可以为:
所述管理服务器根据本地存储的所述MTCDevice触发消息的生命周期,确定当前剩余的生命周期的时长。
如果当前剩余的生命周期的时长大于或等于与所述标识信息相对应的计时器的计时周期的时长,则所述管理服务器确定所述MTCDevice触发消息满足重传条件。
如果当前剩余的生命周期的时长小于与所述标识信息相对应的计时器的计时周期的时长,则所述管理服务器确定所述MTCDevice触发消息不满足重传条件。
步骤S407、所述管理服务器在本地删除绑定存储的所述MTCDevice触发消息与所述标识信息,以及所述MTCDevice触发消息的生命周期,并上报所述MTCDevice触发消息触发失败。
需要说明的是,是否在本发明实施例所提出的技术方案中引入上述的生命周期的处理机制和/或基于计时器的重传机制可以根据实际的需要进行确定,由此而产生的相应的处理方案的变化并不会影响本发明的保护范围。
无论采用上述的哪种方案,所述标识信息均需要满足至少能够临时的唯一标识传输MTCDevice触发消息的过程,或者至少能够临时的唯一标识MTCDevice触发消息的要求,其具体的形式可以包括:
所述管理服务器为本次MTCDevice触发消息及其后续消息的传输过程分配的事务标识;或,
所述管理服务器为所述MTCDevice触发消息分配的序列号。
在实际应用中,具体采用上述的哪种形式可以根据需要进行选择,这样的变化并不影响本发明的保护范围。
相对应的,对于此种方案,在终端设备侧的相应处理过程如下:
当终端设备成功接收到管理服务器所发送的携带标识信息和MTCDevice触发消息的第一消息时,所述终端设备向所述管理服务器发送携带所述标识信息和对所述MTCDevice触发消息的确认消息的第二消息。
其中,所述标识信息需要满足的要求及其具体形式参见前述说明,在此不再赘述。
具体的处理方式参见上述说明,与之相类似,在此,不再重复说明。
与现有技术相比,本发明实施例所提出的技术方案具有以下优点:
通过应用本发明实施例的技术方案,以管理服务器(例如MME或SGSN)为判断主体,在向终端设备发送MTCDevice触发消息时,携带相应的标识信息,并根据是否接收到终端设备所返回的携带同样标识信息的确认消息,来确定相应的MTCDevice触发消息是否投递成功,从而,解决现有技术中不能确定MTCDevice触发消息是否投递成功的问题,能够准确的确定MTCDevice触发消息是否被终端设备成功接收,提高了MTCDevice触发消息投递过程的可靠性。
下面,结合具体的应用场景,对本发明实施例所提出的技术方案进行说明。
本发明实施例所提出的技术方案中,针对现有技术的问题,特别是针对MME/SGSN收到多个MTCDeviceTrigger的场景,提供了一种MTCDeviceTrigger消息的的投递确认方法,从而,能够准确的确定MTCDevice触发消息是否被终端设备成功接收,提高了MTCDevice触发消息投递过程的可靠性。
为了方便描述,本发明实施例具体以MME/SGSN作为前述的管理服务器的具体示例进行说明,在实际的应用场景中,具体管理服务器的类型变化并不会影响本发明的保护范围。
相应的,在以MME/SGSN作为DeviceTrigger是否传递成功的判决点,并使用标识信息来关联Trigger消息和投递确认消息的场景下,具体的实施例说明如下。
如图5所示,为本发明实施例所提出的一种具体应用场景下的MTCDevice触发消息的投递确认方法的流程示意图,该方法具体包括以下步骤:
步骤S501、MME/SGSN在封装Trigger消息时,为每一条Trigger分配交易标识Transactionidentifier(Transactionidentifier是用来关联一个消息流程的),将每个Trigger消息与一个Transactionidentifier绑定并存储。
具体的,在图5所示的本步骤的处理过程中,TriggerMessage是MTCServer下发的消息,在DOWNLINKGENERICNASTRANSPORT消息中封装TransactionIdentifier。
在具体的处理场景中,DOWNLINKGENERICNASTRANSPORT消息的格式如表1所示。
表1DOWNLINKGENERICNASTRANSPORT消息的格式
进一步的,在本步骤中,MME/SGSN选择在Additionalinformation中填入TransactionID,具体的格式如表2所示。
表2Additionalinformation的格式
具体的,可以在表2所示的value部分填入TransactionIdentifier,Transactionidentifier根据具体的场景需要进行设置,具体形式的变化并不影响本发明的保护范围。
步骤S502、MME/SGSN使用NAS信令(如果UE在空闲态,则先要寻呼UE)将Trigger消息传递给UE,同时启动定时器T。
其中,定时器T的取值与具体的实现相关。
例如,假设Trigger生命周期为60s,重传5次,则可以将T设为12s。
步骤S503、UE收到携带Trigger消息的NAS信令后,为每个成功接收的Trigger消息发送确认,在携带确认消息的消息中同样填写相同的Transactionidentifiervalue。
步骤S504、MME/SGSN收到携带Transactionidentifier和确认消息的消息后,MME/SGSN通过消息中的Transactionidentifier确定收到的是对哪条Trigger消息的确认消息,从而删除所存储的该条Trigger消息,并且停止对应的定时器T。
步骤S505、如果MME/SGSN在定时器T超时后,仍然没有收到某Trigger确认消息,如果该Trigger消息的剩余生命周期仍然大于一个完整的定时器T的计时周期,则依据MME/SGSN实现,再次重传Trigger消息。多次超时后(实现相关),判断投递失败,通过HSS/HLR或MTC-IWF向MTCServer报告失败。
与现有技术相比,本发明实施例所提出的技术方案具有以下优点:
通过应用本发明实施例的技术方案,以管理服务器(例如MME或SGSN)为判断主体,在向终端设备发送MTCDevice触发消息时,携带相应的标识信息,并根据是否接收到终端设备所返回的携带同样标识信息的确认消息,来确定相应的MTCDevice触发消息是否投递成功,从而,解决现有技术中不能确定MTCDevice触发消息是否投递成功的问题,能够准确的确定MTCDevice触发消息是否被终端设备成功接收,提高了MTCDevice触发消息投递过程的可靠性。
为了实现本发明实施例的技术方案,本发明实施例还提供了一种管理服务器,其结构示意图如图6所示,至少包括:
分配模块61,用于在根据接收到的触发请求消息生成MTCDevice触发消息时,为所述MTCDevice触发消息分配标识信息;
存储模块62,用于将所述MTCDevice触发消息与所述分配模块61所分配的标识信息进行绑定存储;
发送模块63,用于向终端设备发送携带所述分配模块61所分配的标识信息和所述MTCDevice触发消息的第一消息;
接收模块64,用于接收所述终端设备返回的消息;
判断模块65,用于当所述接收模块64接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息时,判断所述第二消息中所携带的标识信息与所述存储模块62绑定存储的所述标识信息是否一致;
处理模块66,用于在所述判断模块65的判断结果为一致时,确定所述接收模块64所接收到的第二消息中所携带的确认消息是对所述存储模块62绑定存储的所述MTCDevice触发消息的确认消息,通知所述存储模块62删除绑定存储的所述MTCDevice触发消息与所述标识信息,并通知所述发送模块63转发所述接收模块64所接收到的第二消息中所携带的确认消息。
进一步的,所述存储模块62,还用于存储所述MTCDevice触发消息的生命周期。
相应的,所述处理模块66,具体用于:
如果在所述存储模块62所存储的生命周期到达之前,所述接收模块64接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息,并且确定所述第二消息中所携带的确认消息是对所述存储模块62绑定存储的所述MTCDevice触发消息的确认消息,则通知所述存储模块62删除绑定存储的所述MTCDevice触发消息与所述标识信息,以及所述MTCDevice触发消息的生命周期,并通知所述发送模块63转发所述接收模块64所接收到的第二消息中所携带的确认消息;
如果在所述存储模块62所存储的生命周期到达之前,所述接收模块64没有接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息,或在所述存储模块62所存储的生命周期到达之前,所述接收模块64没有接收到携带对本地绑定存储的所述MTCDevice触发消息的确认消息的第二消息,则通知所述存储模块62删除绑定存储的所述MTCDevice触发消息与所述标识信息,以及所述MTCDevice触发消息的生命周期,并通知所述发送模块63上报所述MTCDevice触发消息触发失败。
另一种应用场景下,上述的管理服务器,还包括:
计时模块67,用于在所述发送模块63向终端设备发送携带所述分配模块61所分配的标识信息和所述MTCDevice触发消息的第一消息时,启动与所述标识信息相对应的计时器。
相应的,所述处理模块66,具体用于:
如果在所述计时模块67所启动的计时器超时之前,所述接收模块64接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息,并且确定所述第二消息中所携带的确认消息是对所述存储模块62绑定存储的所述MTCDevice触发消息的确认消息,则通知所述计时模块67停止与所述标识信息相对应的计时器,通知所述存储模块62删除绑定存储的所述MTCDevice触发消息与所述标识信息,并通知所述发送模块63转发所述接收模块64所接收到的第二消息中所携带的确认消息;
如果在所述计时模块67所启动的计时器超时之前,所述接收模块64没有接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息,或在所述计时模块67所启动的计时器超时之前,所述接收模块64没有接收到携带对本地绑定存储的所述MTCDevice触发消息的确认消息的第二消息,则通知所述发送模块63重新向终端设备发送携带所述标识信息和所述MTCDevice触发消息的第一消息,并通知所述计时模块67重新启动与所述标识信息相对应的计时器。
另一种应用场景下,
所述分配模块61,具体用于在根据接收到的触发请求消息生成MTCDevice触发消息时,为所述MTCDevice触发消息分配标识信息;
所述存储模块62,具体用于将所述MTCDevice触发消息与所述分配模块61所分配的标识信息进行绑定存储,并存储所述MTCDevice触发消息的生命周期;
所述发送模块63,具体用于向终端设备发送携带所述分配模块61所分配的标识信息和所述MTCDevice触发消息的第一消息;
计时模块67,用于在所述发送模块63向终端设备发送携带所述分配模块61所分配的标识信息和所述MTCDevice触发消息的第一消息时,启动与所述标识信息相对应的计时器,其中,所述生命周期的时长大于或等于与所述标识信息相对应的计时器的计时周期的时长;
所述接收模块64,具体用于接收所述终端设备返回的消息;
所述判断模块65,具体用于当所述计时模块67所启动的计时器超时之前,所述接收模块64接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息时,判断所述第二消息中所携带的标识信息与所述存储模块62绑定存储的所述标识信息是否一致;
所述处理模块66,具体用于在所述判断模块65的判断结果为一致时,确定所述第二消息中所携带的确认消息是对所述存储模块62绑定存储的所述MTCDevice触发消息的确认消息,通知所述计时模块67停止与所述标识信息相对应的计时器,通知所述存储模块62删除绑定存储的所述MTCDevice触发消息与所述标识信息,以及所述MTCDevice触发消息的生命周期,并通知所述发送模块63转发所述接收模块64所接收到的第二消息中所携带的确认消息。
其中,所述处理模块66,还用于:
如果在所述计时模块67所启动的计时器超时之前,所述接收模块64没有接收到所述终端设备返回的携带标识信息和对MTCDevice触发消息的确认消息的第二消息,或在所述计时模块67所启动的计时器超时之前,所述接收模块64没有接收到携带对本地绑定存储的所述MTCDevice触发消息的确认消息的第二消息,通知所述判断模块65判断所述MTCDevice触发消息是否满足重传条件;
如果所述判断模块65判断满足重传条件,则通知所述发送模块63重新向终端设备发送携带所述标识信息和所述MTCDevice触发消息的第一消息,并通知所述计时模块67重新启动与所述标识信息相对应的计时器;
如果所述判断模块65判断不满足重传条件,则通知所述存储模块62删除绑定存储的所述MTCDevice触发消息与所述标识信息,以及所述MTCDevice触发消息的生命周期,并通知所述发送模块63上报所述MTCDevice触发消息触发失败。
进一步的,所述判断模块65,具体用于:
根据所述存储模块62存储的所述MTCDevice触发消息的生命周期,确定当前剩余的生命周期的时长;
如果当前剩余的生命周期的时长大于或等于与所述标识信息相对应的计时器的计时周期的时长,则判断所述MTCDevice触发消息满足重传条件;
如果当前剩余的生命周期的时长小于与所述标识信息相对应的计时器的计时周期的时长,则判断所述MTCDevice触发消息不满足重传条件。
需要指出的是,所述分配模块61,具体用于为所述MTCDevice触发消息分配至少能够临时的唯一标识传输MTCDevice触发消息的过程,或者至少能够临时的唯一标识MTCDevice触发消息作为标识信息,其中,所述标识信息,具体包括:
为本次MTCDevice触发消息及其后续消息的传输过程分配的事务标识;或,
为所述MTCDevice触发消息分配的序列号。
在实际应用中,上述的管理服务器,具体为MME或SGSN。
进一步的,本发明实施例还提供了一种终端设备,其结构示意图如图7所示,至少包括:
接收模块71,用于接收管理服务器所发送的消息;
发送模块72,用于在所述接收模块71成功接收到所述管理服务器所发送的携带标识信息和MTCDevice触发消息的第一消息时,向所述管理服务器发送携带所述标识信息和对所述MTCDevice触发消息的确认消息的第二消息。
与现有技术相比,本发明实施例所提出的技术方案具有以下优点:
通过应用本发明实施例的技术方案,以管理服务器(例如MME或SGSN)为判断主体,在向终端设备发送MTCDevice触发消息时,携带相应的标识信息,并根据是否接收到终端设备所返回的携带同样标识信息的确认消息,来确定相应的MTCDevice触发消息是否投递成功,从而,解决现有技术中不能确定MTCDevice触发消息是否投递成功的问题,能够准确的确定MTCDevice触发消息是否被终端设备成功接收,提高了MTCDevice触发消息投递过程的可靠性。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到本发明实施例可以通过硬件实现,也可以借助软件加必要的通用硬件平台的方式来实现。基于这样的理解,本发明实施例的技术方案可以以软件产品的形式体现出来,该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM,U盘,移动硬盘等)中,包括若干指令用以使得一台计算机设备(可以是个人计算机,服务器,或网络侧设备等)执行本发明实施例各个实施场景所述的方法。
本领域技术人员可以理解附图只是一个优选实施场景的示意图,附图中的模块或流程并不一定是实施本发明实施例所必须的。
本领域技术人员可以理解实施场景中的装置中的模块可以按照实施场景描述进行分布于实施场景的装置中,也可以进行相应变化位于不同于本实施场景的一个或多个装置中。上述实施场景的模块可以合并为一个模块,也可以进一步拆分成多个子模块。
上述本发明实施例序号仅仅为了描述,不代表实施场景的优劣。
以上公开的仅为本发明实施例的几个具体实施场景,但是,本发明实施例并非局限于此,任何本领域的技术人员能思之的变化都应落入本发明实施例的业务限制范围。