MTC Device触发消息的投递确认方法和设备的制造方法
【技术领域】
[0001] 本发明涉及通信技术领域，特别涉及一种MTCDevice触发消息的投递确认方法和 设备。
【背景技术】
[0002] 在现有技术中，与MTC(MachineTypeCommunication，机器类通信）Device Trigger(设备触发）相关的需求包括：
[0003] 网络应能够基于MTCServer(服务器）发送的触发指示触发MTC终端发起与MTC Server的通信。
[0004] MTC终端应能从网络接收触发指示并建立与MTCServer间的通信。可能的情况包 括：
[0005] 当MTC终端离线（offline)时接收触发指示。
[0006] 当MTC终端在线（online)但没有建立数据连接时接收触发指示。
[0007] 当MTC终端在线（online)并已建立数据连接时接收触发指示。
[0008] 这里需要说明的是，在现有技术中，对应于3GPP(ThirdGenerationPartnership Project，第三代移动通信伙伴计划）网络系统，数据连接是指终端在3GPP网络中建立的 PDP(PacketDataProtocol，分组数据协议）上下文或](PacketDataNetwork，分组数 据网络）连接。
[0009] 而在现有的技术方案中，还提出支持MTCDeviceTrigger特性的HPLMN(Home PublicLandMobileNetwork，本地公用陆地移动网络）提供的用于传输Trigger消息到 本PLMN(PublicLandMobileNetwork，公用陆地移动网络）的接口须满足以下要求。
[0010] -shallallowforprovidingavalidityorlifetimethatindicateshow longthenetworkshouldstorethetriggerrequestwhenitcannotbedeliveredto theUE,e.g.whentheUEisnotreachableorwhenloadcontrolpreventsimmediate delivery
[0011] 即，必须考虑提供生命周期指示网络在不能传递Trigger到UE时（例如UE不可 达或者负载控制而导致不能立刻传送时），网络应该保存该trigger多长时间。
[0012] 另外，MTCDeviceTrigger特性需要满足以下要求。
[0013] -Thenetworkshallbeabletoreportthesuccessorfailureofthe trigger(e.g.duetonetworkcongestion)totheMTCserver,ifsorequestedbythe MTCServer.
[0014] 即，如果MTCServer请求了报告Trigger消息是否成功传输（例如网络拥塞而导 致传输失败），则网络需要向MTCServer报告相关信息。
[0015] 另一方面，为了实现触发MTCDevice的需求，现有技术中提出了使用 NAS(Non-Access-Stratum，非接入层）信令来触发MTCDevice的方法，该方法适用于成功 attached(附着）的UE。
[0016] 具体如图1所示，为现有技术中通过NAS信令触发MTCDevice的方法的流程示意 图，具体包括以下步骤：
[0017] 步骤S101、MTCServer希望联系UE时，向HSS(HomeSubscriberServer，归属用 户服务器）/HLR(HomeLocationRegister，归属位置寄存器）发送Trigger消息。
[0018] 图 1 中所示的为UEapplicationtriggerrequest(UE应用触发请求）。
[0019] 步骤S102、HSS/HLR先验证该trigger请求；再将trigger消息中的 UE的标志转换为3GPP网络能够识别的标志，例如頂SI(InternationalMobile SubscriberldentificationNumber，国际移动用户识别码）；然后将该请求保存在数据库； 最后选择当前正在服务UE的MME(MobilityManagementEntity，移动性管理实体）或者 SGSN(ServingGPRSSupportNode，GPRS服务节点，其中，GPRS，GeneralPacketRadio Service，通用分组无线业务），并将trigger消息发送给servingMME/SGSN，MME/SGSN收 到后需要向HSS/HLR返回确认；MME收到Trigger消息后，保存该Trigger。
[0020] 步骤S103、MME/SGSN将trigger消息封装在NAS信令中，传给UE。
[0021] 如果trigger消息不紧急，则可以在下一次UE和网络进行NAS信令交互的时候传 递；如果trigger消息紧急，则网络应该立刻寻呼UE，并传递该trigger消息。
[0022] 步骤S104、UE收到Trigger信息后，UE使用计数器来判断是否收到重复的 Trigger;UE向MME/SGSN发送NAS信令来确认；然后建立与MTCServer的通信。
[0023] 步骤S105、网络收到UE的确认后，将保存的Trigger删除，并向HSS/HLR返回 Trigger已经传递的确认。
[0024] 在此方法中，HSS/HLR也可以是一个能够实现上述功能的中间节点，例如 MTC-IWF(Inter-workingFunction，互动功能单元）〇
[0025] 另一方面，现有技术中的SMS(ShortMessageService，短信业务）机制存在确认 机制，MME/SGSN只需转发UE上报的投递报告。
[0026] 具体如图2所示，为现有技术中SMS机制中的确认机制的流程示意图，在该图中 所示的步骤S211至步骤S212,MME收到UE上传的投递报告后，仅仅转发至GMSC(Gateway MobileSwitchingCenter，网关移动交换中心），然后由GMSC来控制是否重传短消息。
[0027] 在实现本发明的过程中，发明人发现现有技术中至少存在以下问题：
[0028] 当网络收到某个UE的多个Trigger时（多个MTCServer发出的Trigger和一个 MTCServer发出多个Trigger的场景），如果存在Trigger消息投递不成功，则网络不能区 分当前哪些成功投递，哪些不成功；例如：
[0029] 根据现有技术，当UE处于连接态，网络使用DOWNLINKGENERICNASTRANSPORT 消息封装一条Trigger消息，传递到UE后，又收到一条新的来自相同或者不同MTCServer 的Trigger消息时，此时UE不能根据计数器来判断收到重复的Trigger消息，因为这两条 Trigger的内容可能是不同的，例如可能是触发建立不同的FON连接，因此，如果UE只收到 一条Trigger消息，并使用DOWNLINKGENERICNASTRANSPORT消息封装了确认消息返回给 网络时，网络不知道该确认是针对哪条的Trigger消息的。
【发明内容】
[0030] 本发明实施例提供一种MTCDevice触发消息的投递确认方法和设备，解决现有的 技术方案中不能准确确认MTCDevice触发消息是否投递成功的问题。
[0031] 为达到上述目的，本发明实施例一方面提供了一种MTCDevice触发消息的投递确 认方法，至少包括以下步骤：
[0032] 当管理服务器根据接收到的触发请求消息生成MTCDevice触发消息时，所述管理 服务器为所述MTCDevice触发消息分配标识信息，并将所述MTCDevice触发消息与所述 标识信息在本地绑定存储；
[0033] 所述管理服务器向终端设备发送携带所述标识信息和所述MTCDevice触发消息 的第一消息；
[0034] 当所述管理服务器接收到所述终端设备返回的携带标识信息和对MTCDevice触 发消息的确认消息的第二消息时，所述管理服务器判断所述第二消息中所携带的标识信息 与本地绑定存储的所述标识信息是否一致；
[0035] 如果一致，所述管理服务器确定所述第二消息中所携带的确认消息是对本地绑定 存储的所述MTCDevice触发消息的确认消息，在本地删除绑定存储的所述MTCDevice触 发消息与所述标识信息，并转发所述第二消息所携带的确认消息。
[0036] 另一方面，本发明实施例还提供了一种管理服务器，至少包括：
[0037] 分配模块，用于在根据接收到的触发请求消息生成MTCDevice触发消息时，为所 述MTCDevice触发消息分配标识信息；
[0038] 存储模块，用于将所述MTCDevice触发消息与所述分配模块所分配的标识信息进 行绑定存储；
[0039] 发送模块，用于向终端设备发送携带所述分配模块所分配的标识信息和所述MTC Device触发消息的第一消息；
[0040] 接收模块，用于接收所述终端设备返回的消息；
[0041] 判断模块，用于当所述接收模块接收到所述终端设备返回的携带标识信息和对 MTCDevice触发消息的确认消息的第二消息时，判断所述第二消息中所携带的标识信息与 所述存储模块绑定存储的所述标识信息是否一致；
[0042] 处理模块，用于在所述判断模块的判断结果为一致时，确定所述接收模块所接收 到的第二消息中所携带的确认消息是对所述存储模块绑定存储的所述MTCDevice触发消 息的确认消息，通知所述存储模块删除绑定存储的所述MTCDevice触发消息与所述标识信 息，并通知所述发送模块转发所述接收模块所接收到的第二消息中所携带的确认消息。
[0043] 另一方面，本发明实施例还提供了一种MTCDevice触发消息的投递确认方法，至 少包括以下步骤：
[0044]当终端设备成功接收到管理服务器所发送的携带标识信息和MTCDevice触发 消息的第一消息时，所述终端设备向所述管理服务器发送携带所述标识信息和对所述MTC Device触发消息的确认消息的第二消息。
[0045] 另一方面，本发明实施例还提供了一种终端设备，至少包括：
[0046] 接收模块，用于接收管理服务器所发送的消息；
[0047] 发送模块，用于在所述接收模块成功接收到所述管理服务器所发送的携带标识信 息和MTCDevice触发消息的第一消息时，向所述管理服务器发送携带所述标识信息和对所 述MTCDevice触发消息的确认消息的第二消息。
[0048]与现有技术相比，本发明实施例所提出的技术方案具有以下优点：
[0049] 通过应用本发明实施例的技术方案，以管理服务器（例如MME或SGSN)为判断主 体，在向终端设备发送MTCDevice触发消息时，携带相应的标识信息，并根据是否接收到终 端设备所返回的携带同样标识信息的确认消息，来确定相应的MTCDevice触发消息是否投 递成功，从而，解决现有技术中不能确定MTCDevice触发消息是否投递成功的问题，能够准 确的确定MTCDevice触发消息是否被终端设备成功接收，提高了MTCDevice触发消息投 递过程的可靠性。
【附图说明】
[0050] 图1为现有技术中通过NAS信令触发MTCDevice的方法的流程示意图；
[0051 ] 图2为现有技术中SMS机制中的确认机制的流程示意图；
[0052] 图3为本发明实施例所提出的一种MTCDevice触发消息的投递确认方法的流程 示意图；
[0053] 图4为本发明实施例提出的一种同时引入生命周期的处理机制和基于计时器的 重传机制的MTCDevice触发消息的投递确认方法的流程示意图；
[0054] 图5为本发明实施例