本申请涉及无线通信技术领域，尤其涉及一种状态信息处理方法及设备。
背景技术：
为了满足公共安全对移动通信的要求，3gpp(3rdgenerationpartnershipproject；第三代合作伙伴计划)组织在release13中引入了mcptt(missioncriticalpushtotalk)技术实现对公共安全通信领域语音通信的支持。在release14中引入对紧急数据业务的支持，该紧急数据业务包含短数据服务、文件分发服务和数据流服务三种类型的子服务。
所谓短数据服务可以理解为传输数据的字节数比较少的数据传输服务，例如：短消息服务可以称之为一种短数据服务。短数据服务通常应用在石油、天然气、海事、航空、公用基础设施以及政府和军事部门等部门的数据传输中。
在实际应用中，发送者向服务器发送待发送的数据，由服务器将发送者发送的数据发送给接收者。在这一数据传输过程中，很多时候发送者不关心所发送的数据的发送状态，但是在特殊领域，发送者需要及时了解数据的发送状态。
由此可见，亟需一种状态信息处理方法，以便于实现发送者及时问询数据的发送状态，以满足用户的实际需求。
技术实现要素：
有鉴于此，本申请实施例提供了一种状态信息处理方法及设备，用于解决现有技术中发送者无法及时问询数据的发送状态的问题。
本申请实施例提供了一种状态信息处理方法，包括：
服务器接收状态信息查询请求，所述状态信息查询请求中包含查询条件，所述状态信息查询请求用于查询满足所述查询条件的数据的传输状态，所述查询条件中包含用户数据服务标识信息、数据传输组标识中的至少一种；
所述服务器从状态信息数据库中查找满足所述查询条件的数据的传输状态信息，并发送查找到的所述传输状态信息；
所述状态信息数据库中存储不同客户端之间所传输数据的传输状态信息。
本申请实施例提供了一种状态信息处理设备，包括：
接收单元，用于接收状态信息查询请求，所述状态信息查询请求中包含查询条件，所述状态信息查询请求用于查询满足所述查询条件的数据的传输状态，所述查询条件中包含用户数据服务标识信息、数据传输组标识中的至少一种；
处理单元，用于从状态信息数据库中查找满足所述查询条件的数据的传输状态信息，并发送查找到的所述传输状态信息；
所述状态信息数据库中存储不同客户端之间所传输数据的传输状态信息。
本申请实施例提供的至少一个实施例所到达的有益效果如下：
本申请实施例通过状态信息数据库对不同客户端之间所传输数据的传输状态信息的收集和存储，在接收到状态信息查询请求时，可以从存储的状态信息数据库中，查找满足状态信息查询请求所包含的查询条件的状态信息，以实现对状态信息的问询。通过本申请实施例提供的技术方案，有效增加支持短数据服务的服务器的数据投递状态查询功能，使得客户端在传输数据之后能够及时查询数据传输状态。
附图说明
为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简要介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域的普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。
图1为本申请实施例提供的一种状态信息处理方法的流程示意图；
图2为本申请实施例提供的一种状态信息处理方法的流程示意图；
图3为本申请实施例提供的一种状态信息处理方法的流程示意图；
图4为本申请实施例提供的一种状态信息处理设备的结构示意图。
具体实施方式
为了使本申请的目的、技术方案和优点更加清楚，本申请实施例提供了一种状态信息处理方法及设备，通过状态信息数据库对不同客户端之间所传输数据的传输状态信息的收集和存储，在接收到状态信息查询请求时，可以从存储的状态信息数据库中，查找满足状态信息查询请求所包含的查询条件的状态信息，以实现对状态信息的问询。通过本申请实施例提供的技术方案，有效增加支持短数据服务的服务器的数据投递状态查询功能，使得客户端在传输数据之后能够及时查询数据传输状态。
下面结合说明书附图对本申请各个实施例作进一步地详细描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。
图1为本申请实施例提供的一种状态信息处理方法的流程示意图。所述方法可以如下所示。
步骤101：服务器接收状态信息查询请求，所述状态信息查询请求中包含查询条件，所述状态信息查询请求用于查询满足所述查询条件的数据的传输状态。
其中，所述查询条件中包含用户数据服务标识信息、数据传输组标识中的至少一种。
需要说明的是，本申请实施例中记载的用户数据服务标识信息可以理解为用户数据服务id，不同用户对应的用户数据服务标识信息不同，即不同用户所使用的客户端对应的用户数据服务标识信息也不同，同一个用户使用不同客户端对应的用户数据服务标识相同。
具体地，用户使用用户账户(例如：用户名密码)登录客户端，通过客户端向mc系统发起认证授权请求，mc系统在认证通过后，为该用户使用的客户端分配数据服务标识mcdataid，作为该用户接入mcdata服务的用户数据服务标识。
在本申请实施例中，服务器接收客户端发送的状态信息查询请求，该状态信息查询请求可以是一对一短数据传输状态信息查询请求，即发送方和接收方分别为一个客户端，例如：作为发送方的第一客户端和作为接收方的第二客户端，第一客户端向第二客户端发送数据，那么这里的状态信息查询请求可以理解为第一客户端向第二客户端发送数据的状态信息查询请求，该状态信息查询请求可以是第一客户端发送的，也可以是第二客户端发送的，这里不做具体限定。
该状态信息查询请求还可以是一对多短数据传输状态信息查询请求，即发送方为一个客户端，接收方为至少两个客户端，例如：作为发送方的第一客户端和作为接收方的至少两个第二客户端，第一客户端分别向不同的第二客户端发送数据，那么这里的状态信息查询请求可以理解为第一客户端向不同的第二客户端发送数据的状态信息查询请求，该状态信息查询请求可以是第一客户端发送的，也可以是不同的第二客户端发送的，这里不做具体限定。
较优地，服务器在接收到状态信息查询请求的情况下，对发送者身份进行验证，以确定发送者是否具备查询状态信息的权限。若不具备查询状态信息的权限，那么向发送者返回查询失败消息。若具备查询状态信息的权限，那么触发执行步骤102。
步骤102：所述服务器从状态信息数据库中查找满足所述查询条件的数据的传输状态信息，并发送查找到的所述传输状态信息。
其中，所述状态信息数据库中存储不同客户端之间所传输数据的传输状态信息。
在本申请实施例中，首先说明一下服务器中状态信息数据库的产生方式。状态信息数据库的产生方式包括但不限于以下方式：
服务器接收第一客户端发送的第一数据处理请求，所述第一数据处理请求中包含第二客户端的标识信息；
所述服务器根据所述第二客户端的标识信息，将所述第一数据处理请求转发给所述第二客户端；
所述服务器将所述第一数据处理请求的传输状态设置为已发送，建立所述第一客户端的用户数据服务标识信息、所述第二客户端的用户数据服务标识信息、所述第一数据处理请求以及传输状态为已发送之间的对应关系；
所述服务器将所述对应关系存储至状态信息数据库中。
需要说明的是，这里记载的第二客户端的标识信息与第二客户端的用户数据服务标识信息是不同的，这里的第二客户端的标识信息可以理解为指明第二客户端的设备标识，而这里的第二客户端的用户数据服务标识信息可以理解为通过第二客户端登录的用户对应的用户数据服务标识信息。
如表1所示，为本申请实施例中记载的状态信息数据库的结构示意图。
表1
从表1中可以看出，状态信息数据库中除了存储对应关系之外，还可以存储该对应关系产生的时间或者数据对象的处理时间，这里不做具体限定。
这里的“已发送”可以理解为服务器已经将第一客户端发送的第一数据处理请求装发给第二客户端。
较优地，所述方法还包括：
若所述第一数据处理请求中包含请求第二客户端发送数据处理回执，那么所述服务器接收所述第二客户端发送的数据处理通知消息，所述数据处理通知消息用于表征所述第二客户端启动对所述第一数据处理请求的处理；
所述服务器将所述数据处理通知消息发送给所述第一客户端。
具体地，在本申请实施例中，有些第一客户端具备支持请求接收端设备发送接收回执和/或数据处理回执的能力，而有些第一客户端不具备支持请求接收端设备发送接收回执和/或数据处理回执的能力。那么在本申请实施例中，一旦所述第一数据处理请求中包含请求第二客户端发送数据处理回执，则说明第一客户端具备支持请求接收端设备发送接收回执和/或数据处理回执的能力，那么第二客户端在接收到服务器发送的第一数据处理请求的情况下，将向服务器发送数据处理通知消息，以便于服务器将该数据处理它通知消息发送给第一客户端，使得第一客户端确定该第一数据处理请求已被第二客户端处理。
较优地，所述方法还包括：
所述服务器在接收所述第二客户端发送的数据处理通知消息的情况下，将所述第一数据处理请求的处理状态设置为第二客户端已处理，建立所述第一客户端的用户数据服务标识信息、所述第二客户端的用户数据服务标识信息、所述第一数据处理请求以及处理状态为已处理之间的对应关系，并将所述对应关系存储至状态信息数据库中。
如表2所示，为本申请实施例中记载的状态信息数据库的结构示意图。
表2
从表2中可以看出，状态信息数据库中可以记录一条数据处理请求在不同时间的状态信息。这里的“已处理”可以理解为第二客户端接收到服务器发送的第一数据处理请求，并对该第一数据处理请求进行处理。
较优地，所述方法还包括：
所述服务器接收所述第一客户端发送的消息读取通知，所述消息读取通知用于表征所述第一客户端读取所述数据处理通知消息；
所述服务器将所述第一数据处理请求的投递状态设置为第一客户端已阅读，建立所述第一客户端的用户数据服务标识信息、所述第二客户端的用户数据服务标识信息、所述第一数据处理请求以及投递状态为已阅读之间的对应关系，并将所述对应关系存储至状态信息数据库中。
如表3所示，为本申请实施例中记载的状态信息数据库的结构示意图。
表3
从表3中可以看出，状态信息数据库中可以记录一条数据处理请求在不同时间的状态信息。这里的“已阅读”可以理解为第二客户端在对第一数据处理请求进行处理，并向服务器返回数据处理通知消息；服务器将该数据处理通知消息发送给第一客户端，第一客户端向服务器发送确认消息，该确认消息可以视为第一客户端已读取该数据处理通知消息。
在本申请实施例中，所述服务器从状态信息数据库中查找满足所述查询条件的数据的传输状态信息的方式包括但不限于：
若所述查询条件中包含发送端设备的用户数据服务标识信息，那么所述服务器从状态信息数据库中查找发送者的用户数据服务标识信息与所述查询条件中包含的发送端设备的用户数据服务标识信息一致的数据的传输状态信息；
若所述查询条件中包含接收端设备的用户数据服务标识信息，那么所述服务器从状态信息数据库中查找接收者的用户数据服务标识信息与所述查询条件中包含的接收端设备的用户数据服务标识信息一致的数据的传输状态信息；
若所述查询条件中包含数据传输组标识，那么所述服务器从状态信息数据库中查找接收者的用户数据服务标识信息和/发送者的用户数据服务标识信息对应的数据传输组标识与所述查询条件中包含的数据传输组标识一致的数据的传输状态信息。
若所述查询条件中包含发送端设备的用户数据服务标识信息和接收端设备的用户数据服务标识信息，那么所述服务器从状态信息数据库中查找发送者的用户数据服务标识信息与所述查询条件中包含的发送端设备的用户数据服务标识信息一致且接收者的用户数据服务标识信息与所述查询条件中包含的接收端设备的用户数据服务标识信息一致的数据的传输状态信息。
也就意味着，服务器查找的满足查询条件的传输状态信息不止一条，可能是多条，即得到传输状态信息列表。
较优地，在本申请实施例中，服务器在建立上述记载的对应关系之前，还需要判断发送者的状态信息保存功能是否已被激活，如果被激活，那么触发执行建立对应关系操作，并将该对应关系存储至状态信息数据库的操作；否则，则不执行建立和存储操作，或者向发送者发送提示信息，该提示信息用于提示发送者是否开启状态信息保存功能。
需要说明的是，本申请实施例中记载的“第一客户端”和“第二客户端”中“第一”、“第二”没有什么特殊含义，仅用来表示不同的客户端。
基于同一个发明构思，图2为本申请实施例提供的一种状态信息处理方法的流程示意图。
步骤201：第一客户端启动短数据传输服务。
步骤202：第一客户端向服务器发送数据处理请求，所述数据处理请求中携带第二客户端的标识信息。
较优地，该数据处理请求中还可以包含请求第二客户端发送接收回执和/或数据处理回执的信息。
步骤203：服务器对所述第一客户端进行权限验证。
步骤204：服务器在验证通过的情况下，根据所述第二客户端的标识信息，将该数据处理请求发送给第二客户端。
步骤205：服务器将数据处理请求的传输状态设置为已发送，建立并存储所述第一客户端的用户数据服务标识信息、所述第二客户端的用户数据服务标识信息、所述数据处理请求以及传输状态为已发送之间的对应关系。
步骤206：第二客户端接收服务器发送的该数据处理请求，并对该数据处理请求对应的数据内容进行处理。
步骤207：若该数据处理请求中包含请求第二客户端发送数据处理回执，那么所述服务器接收所述第二客户端发送的数据处理通知消息。
所述数据处理通知消息用于表征所述第二客户端启动对所述第一数据处理请求的处理。
步骤208：服务器将所述数据处理通知消息发送给所述第一客户端。
步骤209：服务器将该数据处理请求的处理状态设置为第二客户端已处理，建立并存储所述第一客户端的用户数据服务标识信息、所述第二客户端的用户数据服务标识信息、所述数据处理请求以及处理状态为已处理之间的对应关系。
步骤210：第一客户端读取该数据处理通知消息。
步骤211：服务器接收所述第一客户端发送的消息读取通知，所述消息读取通知用于表征所述第一客户端读取所述数据处理通知消息。
步骤212：服务器将该数据处理请求的投递状态设置为第一客户端已阅读，建立并存储所述第一客户端的用户数据服务标识信息、所述第二客户端的用户数据服务标识信息、所述数据处理请求以及投递状态为已阅读之间的对应关系。
基于同一个发明构思，图3为本申请实施例提供的一种状态信息处理方法的流程示意图。
步骤301：第一客户端启动向多个第二客户端发送数据的短数据传输服务。
具体地，第一客户端可以从预先配置的数据传输组标识集合中选择一个数据传输组标识，那么该数据传输组标识对应多个第二客户端，那么步骤301中所记载的第二客户端可以是该数据传输组标识对应的每一个第二客户端，步骤301中所记载的第二客户端也可以是该数据传输组标识对应的部分第二客户端，这里不做具体限定。也就意味着，第一客户端可以选择数据传输组标识，还可以选择数据传输组标识对应的第二客户端。
步骤302：第一客户端向服务器发送数据处理请求，所述数据处理请求中携带数据传输组标识和/或选择的该数据传输组标识对应的全部或者部分的第二客户端的标识信息。
较优地，该数据处理请求中还可以包含请求第二客户端发送接收回执和/或数据处理回执的信息。
步骤303：服务器对所述第一客户端进行权限验证。
步骤304：服务器在验证通过的情况下，根据数据传输组标识和/或选择的该数据传输组标识对应的全部或者部分的第二客户端的标识信息，分别将该数据处理请求发送给确定的各个第二客户端。
步骤305：服务器将数据处理请求的传输状态设置为已发送，建立并存储所述第一客户端的用户数据服务标识信息、数据传输组标识和/或所述第二客户端的用户数据服务标识信息、所述数据处理请求以及传输状态为已发送之间的对应关系。
下面以确定的各个第二客户端中的一个第二客户端为例进行说明，其他第二客户端的操作方式与其相同，这里不再一一赘述。
步骤306：其中一个第二客户端接收服务器发送的该数据处理请求，并对该数据处理请求对应的数据内容进行处理。
步骤307：若该数据处理请求中包含请求第二客户端发送数据处理回执，那么所述服务器接收该第二客户端发送的数据处理通知消息。
所述数据处理通知消息用于表征该第二客户端启动对所述第一数据处理请求的处理。
步骤308：服务器将所述数据处理通知消息发送给所述第一客户端。
步骤309：服务器将该数据处理请求的处理状态设置为该第二客户端已处理，建立并存储所述第一客户端的用户数据服务标识信息、所述第二客户端的用户数据服务标识信息、所述数据处理请求以及处理状态为已处理之间的对应关系。
步骤310：第一客户端读取该数据处理通知消息。
步骤311：服务器接收所述第一客户端发送的消息读取通知，所述消息读取通知用于表征所述第一客户端读取所述数据处理通知消息。
步骤312：服务器将该数据处理请求的投递状态设置为第一客户端已阅读，建立并存储所述第一客户端的用户数据服务标识信息、该第二客户端的用户数据服务标识信息、所述数据处理请求以及投递状态为已阅读之间的对应关系。
表4为本申请实施例提供的状态信息数据库的结构示意图。
表4
如果状态信息查询请求中包含数据传输组标识，那么通过本申请实施例提供的技术方案，服务器可以按照表4中记载的内容向发送者返回传输状态信息。
需要说明的是，本申请实施例中记载的客户端的用户数据服务标识信息可以理解为用户数据服务id、会话id、处理id等等，这里不做具体限定。
通过本申请提供的上述实施例方式，通过状态信息数据库对不同客户端之间所传输数据的传输状态信息的收集和存储，在接收到状态信息查询请求时，可以从存储的状态信息数据库中，查找满足状态信息查询请求所包含的查询条件的状态信息，以实现对状态信息的问询。通过本申请实施例提供的技术方案，有效增加支持短数据服务的服务器的数据投递状态查询功能，使得客户端在传输数据之后能够及时查询数据传输状态。
基于同一个发明构思，图4为本申请实施例提供的一种状态信息处理设备的结构示意图。所述处理设备包括：接收单元401和处理单元402，其中：
接收单元401，用于接收状态信息查询请求，所述状态信息查询请求中包含查询条件，所述状态信息查询请求用于查询满足所述查询条件的数据的传输状态，所述查询条件中包含用户数据服务标识信息、数据传输组标识中的至少一种；
处理单元402，用于从状态信息数据库中查找满足所述查询条件的数据的传输状态信息，并发送查找到的所述传输状态信息；
所述状态信息数据库中存储不同客户端之间所传输数据的传输状态信息。
在本申请的另一个实施例中，所述处理单元402通过以下方式得到所述状态信息数据库，包括：
接收第一客户端发送的第一数据处理请求，所述第一数据处理请求中包含第二客户端的标识信息；
根据所述第二客户端的标识信息，将所述第一数据处理请求转发给所述第二客户端；
将所述第一数据处理请求的传输状态设置为已发送，建立所述第一客户端的用户数据服务标识信息、所述第二客户端的用户数据服务标识信息、所述第一数据处理请求以及传输状态为已发送之间的对应关系；
将所述对应关系存储至状态信息数据库中。
在本申请的另一个实施例中，所述处理单元402，还用于若所述第一数据处理请求中包含请求第二客户端发送数据处理回执，那么接收所述第二客户端发送的数据处理通知消息，所述数据处理通知消息用于表征所述第二客户端启动对所述第一数据处理请求的处理；
将所述数据处理通知消息发送给所述第一客户端。
在本申请的另一个实施例中，所述处理单元402，还用于在接收所述第二客户端发送的数据处理通知消息的情况下，将所述第一数据处理请求的处理状态设置为第二客户端已处理，建立所述第一客户端的用户数据服务标识信息、所述第二客户端的用户数据服务标识信息、所述第一数据处理请求以及处理状态为已处理之间的对应关系，并将所述对应关系存储至状态信息数据库中。
在本申请的另一个实施例中，所述处理单元402，还用于接收所述第一客户端发送的消息读取通知，所述消息读取通知用于表征所述第一客户端读取所述数据处理通知消息；
将所述第一数据处理请求的投递状态设置为第一客户端已阅读，建立所述第一客户端的用户数据服务标识信息、所述第二客户端的用户数据服务标识信息、所述第一数据处理请求以及投递状态为已阅读之间的对应关系，并将所述对应关系存储至状态信息数据库中。
在本申请的另一个实施例中，所述处理单元402从状态信息数据库中查找满足所述查询条件的数据的传输状态信息，包括：
若所述查询条件中包含发送端设备的标识信息，那么从状态信息数据库中查找发送者的用户数据服务标识信息与所述查询条件中包含的发送端设备的用户数据服务标识信息一致的数据的传输状态信息；
若所述查询条件中包含接收端设备的用户数据服务标识信息，那么从状态信息数据库中查找接收者的用户数据服务标识信息与所述查询条件中包含的接收端设备的用户数据服务标识信息一致的数据的传输状态信息；
若所述查询条件中包含数据传输组标识，那么从状态信息数据库中查找接收者的用户数据服务标识信息和/发送者的用户数据服务标识信息对应的数据传输组标识与所述查询条件中包含的数据传输组标识一致的数据的传输状态信息。
需要说明的是，本申请实施例提供的状态信息处理设备可以通过软件方式实现，也可以通过硬件方式实现，这里不做具体限定。状态信息处理设备通过状态信息数据库对不同客户端之间所传输数据的传输状态信息的收集和存储，在接收到状态信息查询请求时，可以从存储的状态信息数据库中，查找满足状态信息查询请求所包含的查询条件的状态信息，以实现对状态信息的问询。通过本申请实施例提供的技术方案，有效增加支持短数据服务的服务器的数据投递状态查询功能，使得客户端在传输数据之后能够及时查询数据传输状态。
本领域的技术人员应明白，本申请的实施例可提供为方法、装置(设备)、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、cd-rom、光学存储器等)上实施的计算机程序产品的形式。
本申请是参照根据本申请实施例的方法、装置(设备)和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请的优选实施例，但本领域内的技术人员一旦得知了基本创造性概念，则可对这些实施例作出另外的变更和修改。所以，所附权利要求意欲解释为包括优选实施例以及落入本申请范围的所有变更和修改。
显然，本领域的技术人员可以对本申请进行各种改动和变型而不脱离本申请的精神和范围。这样，倘若本申请的这些修改和变型属于本申请权利要求及其等同技术的范围之内，则本申请也意图包含这些改动和变型在内。