CN102860049A - 一种短信处理方法、相关设备及*** - Google Patents

Abstract

本发明实施例的一种短信处理方法，包括：接收来自业务应用服务器的业务短信；判断接收到的所述业务短信是否为消息子包，若是，则将所述业务短信存入所述业务短信中的消息序列号对应的缓存队列中，判断所述缓存队列中的业务短信数量是否与所述业务短信中的子包总数字段值一致，若一致，则依据所述缓存队列中所有业务短信中的子包序号，将所述缓存队列中的所有业务短信的消息体内容合并成原始业务数据后，对所述原始业务数据进行处理，若不一致，则向所述业务应用服务器发送子包重发短信，以指示所述业务应用服务器重新发送所述缓存队列中未包含的业务短信。本发明提供的技术方案实现了对原始业务数据的分包重组处理，提高了短信业务***的可靠性。

Description

一种短信处理方法、 相关 i殳备及*** 技术领域

本发明涉及通信领域， 尤其涉及一种短信处理方法、 相关设备及***。 背景技术

机器对机器通信（M2M, Machine to Machine )是基于智能机器终端， 以 多种通信方式为接入手段， 为客户提供的信息化解决方案， 可用于满足客户对 监控、 指挥调度、 数据采集和测量等方面的信息化需求。

通常， 多个 M2M终端由一个 M2M应用服务器统一调度管理， M2M终端 与 M2M应用服务器之间可通过短信、通用分组无线服务技术（GPRS, General Packet Radio Service)等方式进行数据传输， 如安装在监控车辆上的 M2M终端 可通过内置短信定期上传其状态信息、 M2M应用服务器可通过短信下发车辆 调度指令等。

由于 M2M终端的互联网协议（ IP, Internet Protocol )地址并不是固定的， 且 M2M应用服务器向 M2M终端下发消息的时间也是不可预知的， 因此， 当 M2M应用服务器与 M2M终端采用 GPRS方式进行数据交互时， 则需要 M2M 终端始终连接在线， 这必然造成了网络资源和 M2M终端电量的浪费。 因此， 目前 M2M应用服务器与 M2M终端多采用短信方式进行数据交互， 但是， 采 用短信方式进行数据交互存在如下弊端：

现有的短信机制规定，传输的短信一次性携带的数据量不得超过 140个字 节， 然而在大多数情况下， M2M应用服务器与 M2M终端一次交互的数据量 大于 140个字节， 此时需要对原始业务数据进行分包发送， 由于目前不存在有 效的分包机制，使得接收方即便在接收到发送方发送的所有分包数据时，也很 难有效的将所有分包数据组装成原始业务数据， 另一方面， 当发送方向接收方 发送的业务短信出现丟包时， 接收方无法自动通知发送方进行业务短信重传。 可见，在现有的短信协议下，通过短信方式无法保证 M2M应用服务器与 M2M 终端间能够可靠地实现业务数据的传输。 发明内容

本发明实施例提供了一种短信处理方法、相关设备及***， 可以实现对原 始业务数据的分包重组处理， 提高短信业务***的可靠性。

为解决上述技术问题， 本发明实施例提供以下技术方案：

一种短信处理方法， 包括：

接收来自业务应用服务器的业务短信；

判断接收到的业务短信是否为消息子包， 若是， 则将该业务短信存入该业 务短信中的消息序列号对应的緩存队列中，

判断緩存队列中的业务短信数量是否与緩存队列中的业务短信中的子包 总数字段值一致，

若一致， 则依据緩存队列中所有业务短信中的子包序号， 将緩存队列中的 所有业务短信的消息体内容合并成原始业务数据后， 对原始业务数据进行处 理，

若不一致， 则向业务应用服务器发送子包重发短信， 以指示业务应用服务 器重新发送上述緩存队列中未包含的业务短信。

一种短信处理方法， 包括：

业务应用服务器生成业务短信， 在业务短信为消息子包时， 上述业务短信 包括消息序列号以及子包序号；

向用户设备发送上述业务短信；

若接收到用户设备发送的子包重发短信，则向该用户设备重新发送接收到 的子包重发短信指示的业务短信，上述子包重发短信包括需要重新发送的业务 短信的消息序列号及子包序号。

一种用户设备， 包括：

接收单元， 判断单元， 存储单元， 合并处理单元及发送单元；

上述接收单元， 用于接收来自业务应用服务器的业务短信；

上述判断单元， 用于判断上述接收单元接收到的业务短信是否为消息子 包；

上述存储单元，用于当上述判断单元判断出接收到的业务短信为消息子包 时， 将该业务短信存入该业务短信中的消息序列号对应的緩存队列；

上述判断单元，还用于在上述存储单元将上述业务短信存入上述緩存队列 后，判断上述緩存队列中的业务短信数量是否与该业务短信中的子包总数字段 值一致；

上述合并处理单元，用于当上述判断单元判断出上述緩存队列中的业务短 信数量与上述业务短信中的子包总数字段值一致时，依据上述緩存队列中所有 业务短信中的子包序号，将上述緩存队列中的所有业务短信的消息体内容合并 成原始业务数据后， 对该原始业务数据进行处理；

上述发送单元，用于当上述判断单元判断出上述緩存队列中的业务短信数 量与上述业务短信中的子包总数字段值不一致时，向业务应用服务器发送子包 重发短信， 以指示业务应用服务器重新发送上述緩存队列中未包含的业务短 信。

一种业务应用服务器， 包括：

生成单元， 用于生成业务短信， 在该业务短信为消息子包时， 上述业务短 信包括消息序列号以及子包序号；

发送单元， 用于向用户设备发送上述业务短信；

接收单元， 用于接收用户设备发送的子包重发短信， 上述子包重发短信包 括需要重新发送的业务短信的消息序列号及子包序号；

上述发送单元，还用于在上述接收单元接收到用户设备发送的子包重发短 信时， 向该用户设备重新发送上述子包重发短信指示的业务短信。

一种短信业务***， 包括：

如权利要求 14至 16任一项所述的业务应用服务器， 和 /或包括如权利要 求 9至 13任一项所述的用户设备。

由上可见， 本发明实施例中接收端在判断接收到的业务短信是消息子包 时， 可以利用业务短信中的消息序列号、子包总数和子包序号实现对原始业务 数据的分包重组处理，解决了现有短信机制下接收端无法有效地将接收到的消 息子包重组成原始业务数据的弊端， 同时，接收端在发现接收到的消息子包数 量与子包总数不一致时， 可以向发送端发送子包重发短信，指示发送端重新发 送可能已丟失的消息子包， 避免了因消息子包丟失而无法进行分包重组的问 题， 提高了短信业务***的可靠性。 附图说明

为了更清楚地说明本发明实施例中的技术方案，下面将对实施例描述中所 需要使用的附图作筒单地介绍， 显而易见地， 下面描述中的附图仅仅是本发明 的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提 下， 还可以根据这些附图获得其他的附图。

图 1-a为本发明实施例中的短信处理方法一个实施例流程示意图； 图 1-b为本发明实施例中的自定义协议包格式的实施例结构示意图； 图 2为本发明实施例中的短信处理方法另一个实施例流程示意图； 图 3为本发明实施例中的短信处理方法再一个实施例流程示意图； 图 4为本发明实施例中的短信处理方法另一个实施例流程示意图； 图 5为本发明实施例中的用户设备一个实施例结构示意图；

图 6为本发明实施例中的业务应用服务器一个实施例结构示意图； 图 7为本发明实施例中的短信业务***一个实施例结构示意图。 具体实施方式

本发明实施例提供了一种短信处理方法、 相关设备及***。

为使得本发明的发明目的、 特征、 优点能够更加的明显和易懂， 下面将结 合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、 完整地描 述， 显然， 所描述的实施例仅仅是本发明一部分实施例， 而非全部实施例。

下面对本发明实施例中一种短信处理方法进行描述， 请参阅图 1-a, 本发 明实施例中的短信处理方法包括：

101、 接收来自业务应用服务器的业务短信；

在本发明实施例中， 业务应用服务器通过自定义协议来承载业务数据， 向 用户设备 ( UE , User Equipment )发送承载业务数据的业务短信， 其中， 该用 户设备具体可以是 M2M终端。 在实际应用中， 可将自定义协议栈承载在原始 的短信协议栈之上， 自定义协议包格式可包括： 消息头和消息体。

上述消息体用于承载需传输的业务数据，在实际应用场景中， 上述消息体 可由 TLV构成， TLV是带格式的数字或不定长字符串或字节数组， 可用来动 态扩展消息交互中的数据及参数， 其中， T表示数字或字符串或字节数组的定 义标签 TAG, V则表示数字或字符串或字节数组中有效数据的数值， 而 L表 示该 TLV扩展的有效数据或 V的长度 LENGTH。 在实际应用场景中， 可在上 述消息头中定义如下字段： 总长度、版本号、命令字、 消息序列号、 分包标志、 子包总数和子包序号， 上述各字段的含义说明可如表 1所示。

表 1

可理解的是，上述消息头包含的字段及字段长度可根据具体的应用场景进 行修改、 调整或删减， 另外， 也可依据实际需要对消息头中的字段进行扩展， 此处不作限定。

在一种应用场景下， 上述自定义协议包格式还可包括校验信息字段， 具体 的， 其自定义协议包格式可如图 1-b所示。 业务应用服务器可在发送上述业务 短信前， 采用预定的校验算法对业务短信进行运算，如可通过预定的循环冗余 校验（CRC, cyclic redundancy check )算法对业务短信进行运算， 具体地， 可 结合上述消息头和上述消息体的内容进行运算，得到第一校验码， 将第一校验 码携带在上述校验信息字段中。

102、 判断接收到的业务短信是否为消息子包；

当业务应用服务器向 UE发送大数据量的业务消息时， 需要对该业务消息 进行分包发送， 因此， UE接收到的业务短信有可能是某个业务消息的消息子 包。

在实际应用中， UE可根据接收到的业务短信中的分包标志字段值判断该 业务短信是否为消息子包， 如若解析到该业务短信中的分包标志字段值为 0x01 , 则可说明该业务短信为消息子包， 当然， 业务应用服务器也可通过在业 务短信中携带其它特定的子包标识符， 则 UE可通过判断业务短信中是否包含 该子包标识符来确定该业务短信是否为消息子包， 此处不作限定。

若该业务短信为消息子包，则执行步骤 104,若该业务短信不为消息子包， 而为包含原始业务数据的业务短信， 则执行步骤 103。

103、 提取业务短信的消息体内容， 对消息体内容进行处理；

若接收到的业务短信为包含原始业务数据的业务短信，则 UE可提取该业 务短信的消息体内容， 并对提取的消息体内容进行处理， 如将提取的消息体内 容输出显示、 利用提取的消息体内容生成 4艮表等。

104、 将接收到的业务短信存入緩存队列中；

在实际应用中， 当原始业务数据被分段承载在多条业务短信中时， 上述多 条业务短信将包含相同的消息序列号，以指示上述多条业务短信包含的不同业 务数据来源于同一份原始业务数据。

因此， 当 UE判断出接收到的业务短信为消息子包时， 其可将该业务短信 存入该业务短信中的消息序列号对应的緩存队列中，緩存队列与消息序列号是 ——对应的关系， UE可以才艮据消息序列号唯一地确定緩存队列。 例如， 殳设 UE接收到的业务短信的消息头内容如表 2所示：

表 2

则 UE可以将该业务短信存入消息序列号为 0x00000043的緩存队列中。

105、 判断緩存队列中的业务短信数量是否与该业务短信中的子包总数字 段值一致；

例如， 若 UE接收到包含如表 2所示的消息头的业务短信， 则 UE可在将 该业务短信存入緩存队列后，判断该緩存队列中的业务短信数量是否与该业务 短信中的子包总数字段值一致， 即判断緩存队列中是否已包含 3条业务短信。

若一致， 则执行步骤 106, 若不一致， 则执行步骤 107。

106、 将该緩存队列中的所有业务短信的消息体内容合并成原始业务数据 后进行处理；

在实际应用中，业务短信中的子包序号可指示业务短信包含的数据内容在 原始业务数据中的位置， 如由表 2所示的消息头内容可知，原始业务数据被分 段承载在 3条业务短信中，而表 2对应的业务短信为 3条业务短信的第一条业 务短信， 即其包含的数据内容为原始业务数据的第一个分段内容。

因此， 当上述緩存队列中已包含全部业务短信， 则 UE可依据緩存队列中 所有业务短信中的子包序号， 去除所有业务短信中的消息头， 进一步的， 若业 务短信中还包含校验信息， 则将校验信息一并去除，将所有业务短信的消息体 内容合并成原始业务数据，之后对该原始业务数据进行处理，如输出显示上述 原始业务数据、 利用上述完成数据生成报表等。

107、 向业务应用服务器发送子包重发短信；

当 UE判断出緩存队列中的业务短信数量与该业务短信中的子包总数字段 值不一致时， 向业务应用服务器发送子包重发短信， 当然， UE也可设置一个 等待时间，在 UE判断出緩存队列中的业务短信数量与该业务短信中的子包总 数字段值不一致时， 进一步判断计时时长是否超过预置的等待时间，如可判断 从緩存队列存入第一条业务短信开始的计时是否超过预置的等待时间，若未超 过， 则可重复执行步骤 105 , 若超过， 则表明还有与上述消息序列号对应的业 务短信未存入緩存队列， 该业务短信可能在传输过程中已丟失， UE可向业务 应用服务器发送子包重发短信。

举例说明， 假设当前緩存队列中只包含如表 2所示的业务短信， 则 UE可 向业务应用服务器发送消息体为空，消息头分别如表 3和表 4所示的两条子包 重发短信， 其中， 子包重发短信中携带需要重发的业务短信的消息序列号及子 包序号，以使业务应用服务器通过消息序列号及子包序号可指向唯一的业务短 信， 将该业务短信发送给 UE:

表 3

字段 字段值 总长度 消息头长度 +校验信息长度 版本 业务应用服务器版本信息 命令字 0x0002 消息序列号 0x00000043 分包标志 0x00 子包总数 0x01 子包序号 0x02 表 4

可理解的是，如表 4所示， 当业务应用服务器通过解析发现子包重发短信 中的命令字字段的值为 0x0002, 则可以确定该业务短信的类型为发送子包应 答， 可以不对分包标志和子包总数进行解析， 因此， UE也可不对上述子包重 发短信中的分包标志字段和 /或子包总数字段进行设置， 甚至可以不包括分包 标志字段和 /或子包总数字段， 此处不作限定。

当然， UE也可只向业务应用服务器发送一条子包重发短信， 在该子包重 发短信中向业务应用服务器指示緩存队列中未存入的所有业务短信 ,此处不作 限定。

由上可见，本发明实施例中 UE在判断出接收到的业务短信为消息子包时， 利用业务短信中的消息序列号、子包总数和子包序号实现对原始业务数据的分 包重组处理， 即在接收到包含同一消息序列号的所有业务短信后，将所有业务 短信的消息体内容合并为原始业务数据，解决了现有短信机制下 UE无法有效 地将接收到的消息子包重组成原始业务数据的弊端， 同时， UE在发现接收到 的业务短信数量与子包总数不一致时， 向业务应用服务器发送子包重发短信， 指示业务应用服务器重新发送可能已丟失的业务短信，避免了因业务短信丟失 而无法进行分包重组的问题， 提高了短信业务***的可靠性。 请参阅图 2, 本发明实施例中短信处理方法另一实施例包括： 201、 接收来自业务应用服务器的业务短信；

在本发明实施例中， 业务应用服务器通过自定义协议来承载业务数据， 向 UE发送承载业务数据的业务短信， 在实际应用中， 可将自定义协议栈承载在 原始的短信协议栈之上， 自定义协议包格式可包括： 消息头和消息体。

具体的自定义协议包格式及消息体中各字段的说明可参照图 1 步骤 101 中的描述， 此处不再赘述。

在一种应用场景下， 上述自定义协议包格式还可包括校验信息字段， 具体 的， 其自定义协议包格式可如图 1-b所示。 业务应用服务器可在发送上述业务 短信前， 采用预定的校验算法对业务短信进行运算， 如可通过预定的 CRC, 算法对业务短信进行循环冗余运算， 具体地， 可结合上述消息头和上述消息体 的内容进行运算，得到第一校验码，将第一校验码携带在上述校验信息字段中。

202、 判断接收到的业务短信是否为消息子包；

当业务应用服务器向 UE发送大数据量的业务消息时， 需要对该业务消息 进行分包发送， 因此， UE接收到的业务短信有可能是某个业务消息的消息子 包。

在实际应用中， UE可根据接收到的业务短信中的分包标志字段值判断该 业务短信是否为消息子包， 如若解析到该业务短信中的分包标志字段值为 0x01 , 则可说明该业务短信为消息子包， 当然， 业务应用服务器也可通过在业 务短信中携带其它特定的子包标识符， 则 UE可通过判断业务短信中是否包含 该子包标识符来确定该业务短信是否为消息子包， 此处不作限定。

若该业务短信为消息子包，则执行步骤 204,若该业务短信不为消息子包， 而为包含原始业务数据的业务短信， 则执行步骤 203。

203、 提取业务短信的消息体内容， 对消息体内容进行处理；

若接收到的业务短信为包含原始业务数据的业务短信，则 UE可提取该业 务短信的消息体内容， 并对提取的消息体内容进行处理， 如将提取的消息体内 容输出显示、 利用提取的消息体内容生成 4艮表等。

204、 将接收到的业务短信存入緩存队列中；

在实际应用中， 当原始业务数据被分段承载在多条业务短信中时， 上述多 条业务短信将包含相同的消息序列号，以指示上述多条业务短信包含的业务数 据属于同一份原始业务数据的分段数据。

因此， 当 UE判断出接收到的业务短信为消息子包时， 其可将该业务短信 存入该业务短信中的消息序列号对应的緩存队列中，緩存队列与消息序列号是 ——对应的关系， UE可以根据消息序列号唯一地确定緩存队列。

205、 判断緩存队列中的业务短信数量是否与该业务短信中的子包总数字 段值一致；

例如， 若 UE接收到包含如表 2所示的消息头的业务短信， 则 UE可在将 该业务短信存入緩存队列后，判断该緩存队列中的业务短信数量是否与该业务 短信中的子包总数字段值一致。

若一致， 则执行步骤 206, 若不一致， 则执行步骤 207。

206、 将该緩存队列中的所有业务短信的消息体内容合并成原始业务数据 后进行处理；

在实际应用中，业务短信中的子包序号可指示业务短信包含的数据内容在 原始业务数据中的位置， 如由表 2所示的消息头内容可知，原始业务数据被分 段承载在 3条业务短信中，而表 2对应的业务短信为 3条业务短信的第一条业 务短信， 即其包含的数据内容为原始业务数据的第一个分段内容。

因此， 当上述緩存队列中已包含全部业务短信， 则 UE可依据緩存队列中 所有业务短信中的子包序号， 去除所有业务短信中的消息头， 进一步的， 若业 务短信中还包含校验信息， 则将校验信息一并去除，将所有业务短信的消息体 内容合并成原始业务数据，之后对该原始业务数据进行处理，如输出显示上述 原始业务数据、 利用上述完成数据生成报表等。

207、 判断是否超过预置的等待时间；

若緩存队列中的业务短信数量与存入緩存队列中的业务短信的子包总数 字段值不一致，则可判断从緩存队列存入第一条业务短信开始的计时是否超过 预置的等待时间， 可理解， 终端可在某一空緩存队列存入第一条业务短信时启 动计时器开始计时， 若计时时长超过预置的等待时间， 而该緩存队列中仍未存 入全部业务短信， 则执行步骤 208, 若计时时长未超过预置的等待时间， 则执 行步骤 205。

可理解的是， 在计时时长未超过预置的等待时间的等待过程中， 步骤 101 至 104可能执行两次以上。

208、 向业务应用服务器发送子包重发短信；

若从緩存队列存入第一条业务短信开始的计时已超过预置的等待时间，而 緩存队列中的业务短信总数仍与存储在该緩存队列中的业务短信中的子包总 数字段值不一致， 则表明緩存队列中未存入的业务短信可能已丟失， UE可向 业务应用服务器发送子包重发短信，以指示该业务应用服务器重新发送上述緩 存队列中未存入的业务短信。

具体地， 假设计时时长超过预置等待时间， 而緩存队列中只包含如表 2 所示的业务短信， 则 UE可向业务应用服务器发送消息体为空， 消息头分别如 表 3和表 4所示的两条子包重发短信， 其中， 子包重发短信中携带需要重发的 业务短信的消息序列号及子包序号，以使业务应用服务器通过消息序列号及子 包序号可指向唯一的业务短信， 将该业务短信发送给 UE:

可理解的是，如表 4所示， 当业务应用服务器通过解析发现子包重发短信 中的命令字字段的值为 0x0002, 则可以确定该业务短信的类型为发送子包应 答， 可以不对分包标志和子包总数进行解析， 因此， UE也可不对上述子包重 发短信中的分包标志字段和 /或子包总数字段进行设置， 甚至可以不包括分包 标志字段和 /或子包总数字段， 此处不作限定。

当然， UE也可只向业务应用服务器发送一条子包重发短信， 在该子包重 发短信中向业务应用服务器指示緩存队列中未存入的所有业务短信 ,此处不作 限定。

由上可见，本发明实施例中 UE在判断出接收到的业务短信为消息子包时， 利用业务短信中的消息序列号、子包总数和子包序号实现对原始业务数据的分 包重组处理， 即在接收到包含同一消息序列号的所有业务短信后，将所有业务 短信的消息体内容合并为原始业务数据，解决了现有短信机制下 UE无法有效 地将接收到的消息子包重组成原始业务数据的弊端， 同时， UE在发现接收到 的业务短信数量与子包总数不一致， 且等待的计时时长超过预置的等待时间 后， 向业务应用服务器发送子包重发短信，指示业务应用服务器重新发送可能 已丟失的业务短信，避免了因业务短信丟失而无法进行分包重组的问题，提高 了短信业务***的可靠性。 请参阅图 3 , 本发明实施例中短信处理方法另一实施例包括：

301、 接收来自业务应用服务器的业务短信；

其具体内容可与图 1中的步骤 101类似， 可参照步骤 101中的描述， 此处 不再赘述。

302、 获取业务短信中的第一校验码；

在实际应用中，业务应用服务器可利用预定的校验算法对即将发送的业务 短信进行运算， 如可通过预定的 CRC算法对该业务短信进行运算得到第一校 验码，将得到的第一校验码携带在该业务短信中， 如可将该第一校验码携带在 该业务短信的校验信息字段中， 当然， 业务应用服务器也可利用预定的其它校 验算法对该业务短信进行运算， 如消息摘要（MD, Message Digest )算法、 安 全散列算法（SHA, Secure Hash Algorithm )等， 此处不作限定。

UE在接收到该业务短信后， 从该业务短信中获取上述第一校验码， 如可 从上述校验信息字段中获取上述第一校验码。

303、 对接收到的业务短信进行运算， 得到第二校验码；

UE可采用预定的校验算法对接收到的业务短信进行运算， 得到第二校验 码。

在实际应用中， UE在接收到业务短信后， 可利用原有的短信协议和自定 义协议对该业务短信进行解析， 获取上述消息头和消息体， 结合获取到的消息 头和消息体的内容进行运算， 得到第二校验码。

可理解的是， UE使用的校验算法与业务应用服务器使用的校验算法是一 致的， 即若业务应用服务器计算第一校验码采用的是 16位的 CRC算法， 则 UE同样也采用 16位的 CRC算法计算第二校验码。

304、 将第一校验码与第二校验码进行比较， 判断是否一致；

UE将计算出的第二校验码与接收到的业务短信中的第一校验码进行比 较， 以此验证业务短信内容的完整性。 若比较结果不一致， 则说明业务短信包 含的业务数据不完整， 执行步骤 305; 若比较结果一致， 则可说明该业务短信 包含的业务数据是完整的， 执行步骤 306。

305、 向业务应用服务器发送数据重发短信；

当步骤 304的比较结果不一致时， UE向业务应用服务器发送数据重发短 信， 以指示业务应用服务器重新发送该业务短信。

在实际应用中， 若 UE接收到的业务短信的消息头内容如表 5所示， 则 UE可向业务应用服务器发送消息体为空，消息头如表 6所示的数据重发短信， 其中，数据重发短信中携带需要重发的业务短信的消息序列号及子包序号， 以 使业务应用服务器通过消息序列号及子包序号可指向唯一的业务短信，将该业 务短信发送给 UE:

表 5

字段 字段值 总长度 消息头长度 +消息体长度 +校验信息长度 版本 业务应用服务器版本信息 命令字 0x0001 消息序列号 0x0000003F 分包标志 0x01 子包总数 0x02 子包序号 0x01 表 6

字段 字段值 总长度 消息头长度 +校验信息长度 版本 业务应用服务器版本信息 命令字 0x0002 消息序列号 0x0000003F 分包标志 0x00 子包总数 0x01 子包序号 0x01 则业务应用服务器在接收到该数据重发短信后， 向该 UE重新发送消息序 列号为 0x0000003F, 子包序号为 0x01的业务短信。 可理解的是， 当业务应用 服务器通过解析数据重发短信中的命令字字段获知该数据重发短信的类型为 发送子包应答时， 其可不再对分包标志和子包总数进行解析， 因此， UE也可 不对上述数据重发短信中的分包标志字段和 /或子包总数字段进行设置， 甚至 可以不包括分包标志字段和 /或子包总数字段， 此处不作限定。

可以理解的是， 在需要重发的业务短信为包含原始业务短信的业务短信， 则数据重发短信可以不包括子包序号。

306、 判断接收到的业务短信是否为消息子包；

在实际应用中， UE可根据接收到的业务短信中的分包标志字段值判断该 业务短信是否为消息子包， 如若解析到该业务短信中的分包标志字段值为 0x01 , 则可说明该业务短信为消息子包， 当然， 业务应用服务器也可通过在业 务短信中携带其它特定的子包标识符， 则 UE可通过判断业务短信中是否包含 该子包标识符来确定该业务短信是否为消息子包， 此处不作限定。

若该业务短信为消息子包，则执行步骤 307,若该业务短信不为消息子包， 则执行步骤 308。

307、 对该业务短信进行分包重组处理；

在实际应用中， UE若发现接收到的业务短信是消息子包， 则可对该业务 短信进行分包重组处理，其具体实现过程可参照图 1中的步骤 104~107 ,或者， 图 2中的步骤 204~208, 此处不作赘述。

308、 提取业务短信的消息体内容， 对消息体内容进行处理；

若接收到的业务短信为包含原始业务数据的业务短信，则 UE可提取该业 务短信的消息体内容， 并对提取的消息体内容进行处理， 如将提取的消息体内 容输出显示、 利用提取的消息体内容生成 4艮表等。

由上可见，本发明实施例中 UE在判断出接收到的业务短信为消息子包时， 利用业务短信中的消息序列号、子包总数和子包序号实现对原始业务数据的分 包重组处理， 即在接收到包含同一消息序列号的所有业务短信后，将所有业务 短信的消息体内容合并为原始业务数据，解决了现有短信机制下 UE无法有效 地将接收到的消息子包重组成原始业务数据的弊端， 同时， UE在发现接收到 的业务短信数量与子包总数不一致时，指示业务应用服务器重新发送可能已丟 失的业务短信，避免了因业务短信丟失而无法进行分包重组的问题，提高了短 信业务***的可靠性。 进一步的， 本发明实施例中 UE与业务应用服务器采用 预定的校验算法对业务短信进行运算，使得 UE在判断接收到的业务短信是否 为消息子包之前， 可通过比较得到的两个校验码验证该业务短信的完整性， 并 当发现两个校验码不一致时， 向业务应用服务器发送数据重发短信，指示业务 应用服务器重新发送该业务短信，解决了在现有短信机制下 UE无法对接收到 的短信进行完整性验证的弊端，避免了因接收到不完整的业务短信而使 UE无 法进行正常的业务处理。 下面以业务应用服务器为描述主体，为本发明实施例中的短信处理方法进 行描述， 请参阅图 4, 本发明实施例中的短信处理方法包括：

401、 生成业务短信；

业务应用服务器根据自定义协议定义的包格式，将要发送给 UE的原始业 务数据组装成业务短信， 其中， 当原始业务数据被分段承载在多条业务短信中 时，上述多条业务短信中包含消息序列号字段、子包总数字段和子包序号字段。

业务应用服务器以每条业务短信不超过 140个字节为原则，将预发送的原 始业务数据组装生成一条或者多条业务短信。

在一种应用场景中， 若原始业务数据被分段承载在多条业务短信中时， 业 务应用服务器可为每条业务短信的分包标志字段设定值， 以使 UE在接收到上 述业务短信时， 通过该分包标志字段值判断该业务短信是否为消息子包。

可理解的是， 当原始业务数据被分段承载在多条业务短信中时， 即生成的 业务短信为消息子包时，承载来源于同一份原始业务数据的不同分段数据的各 条业务短信中均包含相同的消息序列号，且上述各条业务短信包含的子包序号 可指示各条业务短信包含的数据内容在原始业务数据中的位置。

进一步的， 在生成业务短信后， 业务应用服务器还可利用预定的校验算法 对业务短信进行运算，得到第一校验码，如可结合业务短信的消息头和消息体 的内容进行运算来得到第一校验码， 并将该第一校验码携带在该业务短信中， 如可将第一校验码承载在业务短信中的校验信息字段中，以便 UE在接收到该 业务短信后， 对该业务短信进行完整性验证。 在实际应用中， 业务应用服务器 可通过预定的 CRC算法对该业务短信进行运算， 当然， 业务应用服务器也可 利用预定的其它校验算法对该业务短信进行运算， 如 MD算法、 SHA算法等， 此处不作限定。

402、 向用户设备发送上述业务短信；

403、 若接收到 UE发送的子包重发短信， 则向该用户设备重新发送该子 包重发短信指示的业务短信；

若业务应用服务器接收到 UE发送的子包重发短信， 则向该 UE发送该子 包重发短信指示的业务短信， 具体的， 可通过接收到的子包重发短信中的消息 序列号、 子包序号唯一确定需要重发的业务短信。

进一步的， 若业务应用服务器接收到 UE发送的数据重发短信， 则业务应 用服务器同样可向该 UE重新发送该数据重发短信指示的业务短信， 具体地， 可以根据数据重发短信携带的消息序列号、或消息序列号及子包序号确定需要 重发的业务短信。 将原始业务数据组装成一个或者多个业务短信，使 UE在接收到业务短信后可 实现对原始业务数据进行分包重组处理，解决了现有短信机制下接收端无法有 效地将接收到的消息子包重组成原始业务数据的弊端，提高了短信业务***的 可靠性。进一步的， 业务应用服务器还可采用预定的校验算法对业务短信进行 运算， 将得到的校验码携带在业务短信中发送给 UE, 使得 UE可在接收到该 业务短信后，通过比较业务短信中的第一校验码及本地对业务短信进行运算得 到的第二校验码来验证该业务短信的完整性，解决了在现有短信机制下 UE无 法对接收到的短信进行完整性验证的弊端，避免了因接收到不完整的业务短信 而使 UE无法进行正常的业务处理。 为便于更好的理解本发明实施例的技术方案，下面以业务应用服务器为数 字城管应用***， 用户设备为城市仪表盘终端为例，对本发明实施例中的短信 处理方法进行详细描述。

首先说明的是，本发明实施例中的数字城管应用***以短信方式周期性地 将城市当前指标数据（如城市问题总数、 高发问题、 问题解决率、 平均周期等 指标）发送到城市仪表盘终端，城市仪表盘终端在接收到上述数据后以报表方 式展示出来。

假设数字城管应用***的接入码为 106570000, 城市仪表盘终端的号码为 1380000000,数字城管应用***需要发送到城市仪表盘终端的指标内容如下所 示： "时间： 2010-10-01

问题总数： 72

区域 A问题总数： 20

区域 B问题总数： 15

区域 C问题总数： 18

区域 D问题总数： 3

区域 E问题总数： 6

区域 F问题总数： 10

分类问题汇总

非法小广告： 4

通路不洁： 20

暴露垃圾： 15

施工占道： 25

油烟污染： 3

井盖丟失： 0

其它： 5"

假设消息体和校验信息字段均由 TLV构成， 且 TLV定义如表 7所示： 表 7

标签值 数据类型 数据长度 标签说明 (字节）

0x0000 字符串 4 日期信息， 如 20101001表示为 07DA03E9

0x0001 字符串 不定长 区域信息

0x0002 数字 不定长 问题数量 0x0003 数字 不定长 非法小广告数量

0x0004 数字 不定长 通路不洁数量

0x0005 数字 不定长 暴露垃圾数量

0x0006 数字 不定长 施工占道数量

0x0007 数字 不定长 油烟污染数量

0x0008 数字 不定长 井盖丟失数量

0x0009 数字 不定长 其它

OxOFFF 字符串 2 16位 CRC摘要

若业务短信中的各字段值均以 16进制表示， 则数字城管应用***根据自 定义协议组装的业务短信的消息体内容可如下:

消息体内容：

0000 0004 07DA03E9——时间： ： 20101001

0001 0002 000A-一区域名称： A

0002 0002 0014— —数量： 20

0001 0002 000B—一区域名称： B

0002 0002 000F—一数量： 15

0001 0002 000C—一区域名称： C

0002 0002 0012— —数量： 18

0001 0002 000D-一区域名称： D

0002 0002 0003— —数量： 3

0001 0002 000E—一区域名称： E

0002 0002 0006— —数量： 6

0001 0002 000F—一区域名称： F

0002 0002 000A-一数量： 10

0003 0002 0004—一非法小广告数量： 4

0004 0002 0014—一通路不洁数量： 20 0005 0002 000F——暴露垃圾数量： 15

0006 0002 001E——施工占道数量： 25

0007 0002 0003——油烟污染数量： 3

0008 0002 0000——井盖丟失数量： 0

0009 0002 0003——其它数量： 5

由上可看出， 该消息体内容已超过 140字节， 因此数字城管应用***将其 拆分成两条业务短信， 即两条消息子包， 假设该业务消息的消息序列号为 0000003F, 则每条业务短信组装后的内容如下：

业务短信 1 :

消息头：

总长度： 0088; 版本： 01 ; 命令字： 0001 ; 消息序列号： 0000003F; 分包标志： 01 ; 子包总数： 02; 子包序号： 01

消息体：

0000 0004 07DA03E9——时间： 20101001

0001 0002 000 A——区域名称： A

0002 0002 0014——数量： 20

0001 0002 000B——区域名称： B

0002 0002 000F——数量： 15

0001 0002 000C——区域名称： C

0002 0002 0012——数量： 18

0001 0002 000D——区域名称： D

0002 0002 0003——数量： 3

0001 0002 000E——区域名称： E

0002 0002 0006——数量： 6

0001 0002 000F——区域名称： F

0002 0002 000 A——数量： 10

0003 0002 0004——非法小广告数量： 4

0004 0002 0014——通路不洁数量： 20

0005 0002 000F——暴露垃圾数量： 15 0006 0002 001E——施工占道数量： 25

0007 0002 0003——油烟污染数量： 3

0008 0002 0000——井盖丟失数量： 0

校验信息：

0FFF 0002 7FF3

业务短信 2:

消息头：

总长度： 001A; 版本： 01 ; 命令字： 0001 ; 消息序列号： 0000003F; 分包标志： 01 ; 子包总数： 02; 子包序号： 02

消息体：

0009 0002 0003——其它数量： 5

校验信息：

0FFF 0002 6F88

数字城管应用***设定短信接入码为 106570000 , 接收方号码为 1380000000,将组装好的两条业务短信发送给城市仪表盘终端。 当城市仪表盘 终端接收到接入码为 106570000的业务短信时，通过接入码获知该业务短信来 自数字城管应用***， 则启动相应的客户端程序（如城市管家客户端程序）对 该业务短信进行处理（完整性验证、 分包重组处理、 原始业务数据处理）。

假设当前城市仪表盘终端当前接收到业务短信 1 , 则执行如下步骤：

A1.获取消息头中的内容：

0088 01 0001 0000003F 01 02 01

A2.获取消息体中的内容：

0000 0004 07DA03E9

0001 0002 000 A

0002 0002 0014

0001 0002 000B

0002 0002 000F

0001 0002 000C

0002 0002 0012 0001 0002 000D

0002 0002 0003

0001 0002 000E

0002 0002 0006

0001 0002 000F

0002 0002 000A

0003 0002 0004

0004 0002 0014

0005 0002 000F

0006 0002 00 IE

0007 0002 0003

0008 0002 0000

A3.获取校验信息字段中的循环冗余校验码：

0FFF 0002 7FF3

A4.利用预定的 16位 CRC算法对获取的消息头和消息体进行运算， 得到 循环冗余校验码， 并与步骤 A3获取到的循环冗余校验码进行比较， 若比较结 果一致， 则表明业务短信 1是完整的， 若比较结果不一致， 则可向数字城管应 用***发送数据重发短信， 该数据重发短信的消息体内容可为空， 消息头内容 可参照表 6所示。

A5.在本发明实施例中假设城市仪表盘终端接收到的业务短信 1 是完整 的， 则其进一步对业务短信 1进行处理， 城市仪表盘终端通过解析业务短信 1 的分包标志（字段值等于 01 ), 判断出业务短信 1为消息子包， 将其存入业务 短信 1的消息序列号 ( 0000003F )对应的緩存队列中。

A6. 城市仪表盘终端发现该緩存队列中只包含业务短信 1 , 而业务短信 1 中的子包总数字段值为 02, 业务短信数量与子包总数字段值不一致， 则判断 从緩存队列中存入业务短信 1 开始的计时是否超过预置的等待时间， 若不超 过， 则重复判断緩存队列中的业务短信数量是否与上述子包总数字段值一致。

以下分两种情况对后续步骤分别进行描述：

B1.若业务短信 2在传输过程中丟失， 则在计时时长超过预置的等待时间 后，城市仪表盘终端向业务应用服务器发送子包重发短信， 该子包重发短信的 消息体内容可为空， 消息头内容可为： 0088 01 0002 0000003F 00 01 02。 数字 城管应用***在接收到该子包重发短信后，重新向城市仪表盘终端发送业务短 信 2。

B2.若城市仪表盘终端接收到了业务短信 2, 则可依据业务短信 1和业务 短信 2中的子包序号字段值，将緩存队列中的业务短信 1和业务短信 2的消息 头和校验信息去除后合并成原始业务数据：

时间： 2010-10-01

问题总数： 72

区域 A问题总数： 20

区域 B问题总数： 15

区域 C问题总数： 18

区域 D问题总数： 3

区域 E问题总数： 6

区域 F问题总数： 10

分类问题汇总

非法小广告： 4

通路不洁： 20

暴露垃圾： 15

施工占道： 25

油烟污染： 3

井盖丟失： 0

其它： 5

城市仪表盘终端可根据得到的原始业务数据生成报表，如绘制出当天整个 城市的问题总数、 高发问题头 5名、 最近一周的问题总数、 问题解决率、 平均 处理周期等指标。

由上可见，本发明实施例中 UE在判断出接收到的业务短信为消息子包时， 利用业务短信中的消息序列号、子包总数和子包序号实现对原始业务数据的分 包重组处理， 即在接收到包含同一消息序列号的所有业务短信后，将所有业务 短信的消息体内容合并为原始业务数据，解决了现有短信机制下 UE无法有效 地将接收到的消息子包重组成原始业务数据的弊端， 同时， UE在发现接收到 的业务短信数量与子包总数不一致时，指示业务应用服务器重新发送可能已丟 失的业务短信，避免了因业务短信丟失而无法进行分包重组的问题，提高了短 信业务***的可靠性。 进一步的， 本发明实施例中 UE与业务应用服务器采用 预定的校验算法对业务短信进行运算，使得 UE在判断接收到的业务短信是否 为消息子包之前， 可通过比较得到的两个校验码验证该业务短信的完整性， 并 当发现两个校验码不一致时， 向业务应用服务器发送数据重发短信，指示业务 应用服务器重新发送该业务短信，解决了在现有短信机制下 UE无法对接收到 的短信进行完整性验证的弊端，避免了因接收到不完整的业务短信而使 UE无 法进行正常的业务处理。 下面对本发明实施例中的用户设备进行描述， 请参阅图 5 , 本发明实施例 中的用户设备 500包括：

接收单元 501 , 判断单元 502, 存储单元 503 , 合并处理单元 504及发送 单元 505。

接收单元 501用于接收来自业务应用服务器的业务短信；

判断单元 502,用于判断接收单元 501接收到的业务短信是否为消息子包； 在实际应用中，判断单元 502具体可依据该业务短信中的分包标志字段值 来判断接收单元 501接收到的业务短信是否为消息子包。

存储单元 503用于当判断单元 502判断出接收到的业务短信为消息子包 时，将接收单元 501接收到的业务短信存入该业务短信中的消息序列号对应的 緩存队列中。

判断单元 502还用于判断緩存队列中的业务短信数量是否与緩存队列中 的业务短信的子包总数字段值一致；

进一步的，判断单元 502还可用于在判断出緩存队列中的业务短信数量与 緩存队列中的业务短信的子包总数字段值不一致时，判断在緩存队列存入第一 条业务短信时开始的计时是否超过预置的等待时间；

合并处理单元 504, 用于当判断单元 502判断出緩存队列中的业务短信数 量与緩存队列中的业务短信的子包总数字段值一致时，依据该緩存队列中所有 业务短信中的子包序号，将该緩存队列中的所有业务短信的消息体内容合并成 原始业务数据后，对该原始业务数据进行处理，如将该原始业务数据输出显示、 利用该原始业务数据生成报表等；

发送单元 505 , 用于当判断单元 502判断出緩存队列中的业务短信数量与 緩存队列中的业务短信的子包总数字段值不一致时，向业务应用服务器发送子 包重发短信，以指示该业务应用服务器重新发送该緩存队列中未存入的业务短 信， 当然，发送单元 505也可在判断单元 502判断出緩存队列中的业务短信数 量与緩存队列中的业务短信中的子包总数字段值不一致， 且在判断单元 502 判断出在该緩存队列存入第一条业务短信时开始的计时超过预置的等待时间 时， 才向业务应用服务器发送子包重发短信。

在实际应用中， 上述业务短信中还可能携带着第一校验码， 该第一校验码 是由业务应用服务器在发送该业务短信前， 依据预定的校验算法（如 CRC、 MD、 SHA等算法）对其生成的业务短信进行运算得到的， 用户设备 500可根 据上述第一校验码对该业务短信进行完整性校验， 具体的， 用户设备 500还可 包括： 运算单元和比较单元。

其中，运算单元用于采用预定的校验算法对接收单元 501接收到的业务短 信进行运算， 得到第二校验码；

在实际应用中，在接收单元 501接收到业务短信后，运算单元可利用原有 的短信协议和自定义协议对接收到的业务短信进行解析，获取业务短信的消息 头和消息体，结合获取到的消息头和消息体的内容进行运算，得到第二校验码。

可理解的是，上述运算单元使用的校验算法与业务应用服务器使用的校验 算法一致。

其中，比较单元用于将接收单元 501接收到的业务短信中的第一校验码与 运算单元得到的第二校验码进行比较；

发送单元 505还可用于当比较单元的比较结果为不一致时，向业务应用服 务器发送数据重发短信， 以指示该业务应用服务器重新发送上述业务短信； 在实际应用中 ,发送单元 505向业务应用服务器发送的数据重发短信的消 息体内容可为空， 其消息头格式可参照表 3所示。

需要说明的是，本实施例的用户设备 500可以如上述方法实施例中的用户 设备， 可以用于实现上述方法实施例中的全部技术方案， 其各个功能模块的功 能可以根据上述方法实施例中的方法具体实现，其具体实现过程可参照上述实 施例中的相关描述， 此处不再赘述。

由上可见，本发明实施例中 UE在判断出接收到的业务短信为消息子包时， 利用业务短信中的消息序列号、子包总数和子包序号实现对原始业务数据的分 包重组处理， 即在接收到包含同一消息序列号的所有业务短信后，将所有业务 短信的消息体内容合并为原始业务数据，解决了现有短信机制下 UE无法有效 地将接收到的消息子包重组成原始业务数据的弊端， 同时， UE在发现接收到 的业务短信数量与子包总数不一致时，指示业务应用服务器重新发送可能已丟 失的业务短信，避免了因业务短信丟失而无法进行分包重组的问题，提高了短 信业务***的可靠性。 进一步的， 本发明实施例中 UE与业务应用服务器采用 预定的校验算法对业务短信进行运算，使得 UE在判断接收到的业务短信是否 为消息子包之前， 可通过比较得到的两个校验码验证该业务短信的完整性， 并 当发现两个校验码不一致时， 向业务应用服务器发送数据重发短信，指示业务 应用服务器重新发送该业务短信，解决了在现有短信机制下 UE无法对接收到 的短信进行完整性验证的弊端，避免了因接收到不完整的业务短信而使 UE无 法进行正常的业务处理。 下面对本发明实施例中的业务应用服务器进行描述， 请参阅图 6, 本发明 实施例中的业务应用服务器 600包括：

生成单元 601 , 用于生成业务短信；

生成单元 601根据自定义协议定义的包格式，将要发送给 UE的原始业务 数据组装成业务短信， 其中， 其中， 当业务数据被分段承载在多条业务短信中 时， 即生成的业务短信为消息子包时， 生成的多条业务短信中可包含消息序列 号、 子包总数和子包序号。

生成单元 601以每条业务短信不超过 140个字节为原则，将预发送的原始 业务数据组装生成一条或者多条业务短信。

在一种应用场景中， 若原始业务数据被分段承载在多条业务短信时， 则生 成单元 601可为业务短信中的分包标志字段设定值， 以使 UE在接收到上述业 务短信时， 通过该分包标志字段值判断该业务短信是否为消息子包。 可理解的是， 当原始业务数据被分段承载在多条业务短信中时，承载来源 于同一份原始业务数据的不同分段数据的各条业务短信中均包含相同的消息 序列号，且上述各条业务短信中的子包序号可指示各条业务短信包含的数据内 容在原始业务数据中的位置。

发送单元 602, 用于向用户设备发送生成单元 601生成的业务短信； 接收单元 603 , 用于接收用户设备发送的子包重发短信；

其中，子包重发短信包括需要重新发送的业务短信的消息序列号及子包序 号；

发送单元 602进一步可用于在接收单元 603接收到 UE发送的子包重发短 信时， 向该用户设备重新发送该子包重发短信指示的业务短信。

进一步的， 业务应用服务器 600还可包括：

运算单元 604， 用于对采用预定的校验算法对生成单元 601生成的业务短 信进行运算， 得到第一校验码， 并将该第一校验码携带在该业务短信中， 如可 承载在业务短信的校验信息字段中；

在实际应用中， 运算单元 604可利用预定的 CRC算法对生成单元 601生 成的业务短信进行运算， 当然,运算单元 604也可利用预定的其它校验算法对 生成单元 601生成的业务短信进行运算， 如 MD算法、 SHA算法等， 此处不 作限定。

进一步的， 接收单元 603还可用于接收用户设备发送的数据重发短信； 发送单元 602还可在接收单元 603接收到用户设备发送的数据重发短信 时， 向该用户设备重新发送数据重发短信中指示的业务短信。

需要说明的是，本实施例的业务应用服务器 600可以如上述方法实施例中 的业务应用服务器， 可以用于实现上述方法实施例中的全部技术方案， 其各个 功能模块的功能可以根据上述方法实施例中的方法具体实现，其具体实现过程 可参照上述实施例中的相关描述， 此处不再赘述。 将原始业务数据组装成一个或者多个业务短信，使 UE在接收到业务短信后可 实现对原始业务数据进行分包重组处理，解决了现有短信机制下接收端无法有 效地将接收到的消息子包重组成原始业务数据的弊端，提高了短信业务***的 可靠性。进一步的， 业务应用服务器还可采用预定的校验算法对业务短信进行 运算， 将得到的校验码携带在业务短信中发送给 UE, 使得 UE可在接收到该 业务短信后，通过比较业务短信中的第一校验码及本地对业务短信进行运算得 到的第二校验码来验证该业务短信的完整性，解决了在现有短信机制下 UE无 法对接收到的短信进行完整性验证的弊端，避免了因接收到不完整的业务短信 而使 UE无法进行正常的业务处理。 下面对本发明实施例中的短信业务***进行描述， 请参阅图 7 , 本发明实 施例中的短信业务*** 700包括：

业务应用服务器 701和至少一个用户设备 702。

其中， 业务应用服务器 701用于： 生成业务短信， 其中， 当上述业务短信 为消息子包时， 生成的业务短信包含消息序列号、 子包总数和子包序号； 用于 向用户设备 702发送业务短信；用于当接收到用户设备 702发送的子包重发短 信时， 向用户设备 702重新发送该子包重发短信指示的业务短信。

进一步的， 业务应用服务器 701还可用于对生成的业务短信进行校验， 并 将得到的第一校验码携带在该业务短信中；用于当接收到用户设备 702发送的 数据重发短信时， 向该用户设备重新发送数据重发短信中指示的业务短信。

其中， 用户设备 702用于接收来自业务应用服务器 701发送的业务短信； 判断接收到的业务短信是否为消息子包； 当接收到的业务短信为消息子包时， 将该业务短信存入该业务短信中的消息序列号对应的緩存队列中，并判断该緩 存队列中的业务短信数量是否与该业务短信中的子包总数字段值一致， 若一 致， 则依据存储在该緩存队列中的所有业务短信的子包序号，将緩存队列中的 所有业务短信的消息体内容合并成完整数据后，对该完整数据进行处理， 如输 出显示上述完整数据、利用上述完成数据生成报表等， 若该緩存队列中的业务 短信数量是否与该业务短信中的子包总数字段值不一致，则向业务应用服务器 701发送子包重发短信， 以指示业务应用服务器 701重新发送緩存队列中未包 含的业务短信；

进一步的，用户设备 702也可在向业务应用服务器 701发送子包重发短信 之前，判断在緩存队列存入第一条业务短信开始的计时是否超过预置的等待时 间， 若超过， 才向业务应用服务器 701发送子包重发短信， 若不超过， 则重新 判断緩存队列中的业务短信数量是否与该业务短信中的子包总数字段值一致。 进一步的， 若接收到的业务短信中携带第一校验码， 则用户设备 702还可 采用预定的校验算法对接收到的业务短信进行校验，得到第二校验码后； 将上 述第一校验码与上述第二校验码进行比较， 若比较结果不一致， 则向该业务应 用服务器 701发送数据重发短信，以指示业务应用服务器 701重新发送上述业 务短信。

需要说明的是，本实施例的业务应用服务器 701可与图 6所示的业务应用 服务器 600类似， 可以如上述方法实施例中的业务应用服务器， 可以用于实现 上述方法实施例中的全部技术方案，其各个功能模块的功能可以根据上述方法 实施例中的方法具体实现， 其具体实现过程可参照上述实施例中的相关描述， 此处不再赘述。

本实施例的用户设备 702可与图 5所示的用户设备 500类似，可以如上述 方法实施例中的用户设备， 可以用于实现上述方法实施例中的全部技术方案 , 其各个功能模块的功能可以根据上述方法实施例中的方法具体实现，其具体实 现过程可参照上述实施例中的相关描述， 此处不再赘述。

由上可见，本发明实施例中的短信业务***解决了现有短信机制下 UE无 法有效地将接收到的消息子包重组成原始业务数据的弊端， 同时， UE在发现 接收到的业务短信数量与子包总数不一致时，指示业务应用服务器重新发送可 能已丟失的业务短信，避免了因业务短信丟失而无法进行分包重组的问题，提 高了短信业务***的可靠性。进一步的， 本发明实施例中的短信业务***还解 决了在现有短信机制下 UE无法对接收到的短信进行完整性验证的弊端，避免 了因接收到不完整的业务短信而使 UE无法进行正常的业务处理。

所属领域的技术人员可以清楚地了解到， 为描述的方便和筒洁， 上述描述 的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程， 在此不再赘述。

在本申请所提供的几个实施例中， 应该理解到， 所揭露的***， 装置和方 法， 可以通过其它的方式实现。 例如， 以上所描述的装置实施例仅仅是示意性 的， 例如， 所述单元的划分， 仅仅为一种逻辑功能划分， 实际实现时可以有另 外的划分方式， 例如多个单元或组件可以结合或者可以集成到另一个***，或 一些特征可以忽略， 或不执行。 另一点， 所显示或讨论的相互之间的耦合或直 接耦合或通信连接可以是通过一些接口， 装置或单元的间接耦合或通信连接， 可以是电性， 机械或其它的形式。 单元显示的部件可以是或者也可以不是物理单元， 即可以位于一个地方， 或者 也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部 单元来实现本实施例方案的目的。

另外， 在本发明各个实施例中的各功能单元可以集成在一个处理单元中， 也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元 中。上述集成的单元既可以采用硬件的形式实现， 也可以采用软件功能单元的 形式实现。

所述集成的单元如果以软件功能单元的形式实现并作为独立的产品销售 或使用时， 可以存储在一个计算机可读取存储介质中。 基于这样的理解， 本发 明的技术方案本质上或者说对现有技术做出贡献的部分或者该技术方案的全 部或部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储 介质中， 包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器， 或者网络设备等 )执行本发明各个实施例所述方法的全部或部分步骤。 而前述 的存储介质包括： U盘、 移动硬盘、 只读存储器（ROM, Read-Only Memory )、 随机存取存储器（RAM, Random Access Memory ), 磁碟或者光盘等各种可以 存储程序代码的介质。

以上对本发明所提供的一种短信处理方法、相关设备及***进行了详细介 绍， 对于本领域的一般技术人员， 依据本发明实施例的思想， 在具体实施方式 及应用范围上均会有改变之处， 综上， 本说明书内容不应理解为对本发明的限 制。

Claims (1)

1. 权 利 要 求

   1、 一种短信处理方法， 其特征在于， 包括：

   接收来自业务应用服务器的业务短信；

   判断接收到的所述业务短信是否为消息子包， 若是， 则将所述业务短信存 入所述业务短信中的消息序列号对应的緩存队列中，

   判断所述緩存队列中的业务短信数量是否与所述业务短信中的子包总数 字段值一致，

   若一致， 则依据所述緩存队列中所有业务短信中的子包序号，将所述緩存 队列中的所有业务短信的消息体内容合并成原始业务数据后，对所述原始业务 数据进行处理，

   若不一致， 则向所述业务应用服务器发送子包重发短信， 以指示所述业务 应用服务器重新发送所述緩存队列中未包含的业务短信。

   2、 如权利要求 1所述的短信处理方法， 其特征在于，

   向所述业务应用服务器发送子包重发短信的步骤之前进一步包括： 判断在所述緩存队列存入第一条业务短信时开始的计时是否超过预置的 等待时间， 若超过， 才向所述业务应用服务器发送子包重发短信。

   3、 根据权利要求 1或 2所述的方法， 其特征在于，

   所述业务短信包含分包标志字段；

   所述判断接收到的所述业务短信是否为消息子包具体为：

   根据分包标志字段值判断所述业务短信是否为消息子包。

   4、 根据权利要求 1或 2所述方法， 其特征在于，

   接收到的所述业务短信包括第一校验码；

   所述判断接收到的所述业务短信是否为消息子包的步骤之前包括： 采用预定的校验算法对接收到的业务短信进行运算， 得到第二校验码； 将所述第一校验码与所述第二校验码进行比较，

   若所述第一校验码与所述第二校验码不一致，则向所述业务应用服务器发 送数据重发短信， 以指示所述业务应用服务器重新发送接收到的所述业务短 信。

   5、 根据权利要求 4所述的方法， 其特征在于， 所述采用预定的校验算法对接收到的业务短信进行运算具体为： 采用循环冗余校验算法对接收到的业务短信进行运算。

   6、 一种短信处理方法， 其特征在于， 包括：

   业务应用服务器生成业务短信， 在所述业务短信为消息子包时， 所述业务 短信包括消息序列号以及子包序号；

   向用户设备发送所述业务短信；

   若接收到所述用户设备发送的子包重发短信，则向所述用户设备重新发送 所述子包重发短信指示的业务短信，所述子包重发短信包括需要重新发送的业 务短信的消息序列号及子包序号。

   7、 根据权利要求 6所述的方法， 其特征在于，

   所述向用户设备发送所述业务短信的步骤之前包括：

   采用预定的校验算法对生成的业务短信进行运算，得到第一校验码，将所 述第一校验码携带在生成的业务短信中。

   8、 如权利要求 7所述的方法， 其特征在于， 所述方法还包括：

   若业务应用服务器接收到所述用户设备发送的数据重发短信，则向所述用 户设备重新发送所述数据重发短信指示的业务短信。

   9、 一种用户设备， 其特征在于， 包括：

   接收单元， 判断单元， 存储单元， 合并处理单元及发送单元；

   所述接收单元， 用于接收来自业务应用服务器的业务短信；

   所述判断单元， 用于判断所述接收单元接收到的业务短信是否为消息子 包；

   所述存储单元，用于当所述判断单元判断出接收到的业务短信为消息子包 时， 将所述业务短信存入所述业务短信中的消息序列号对应的緩存队列； 所述判断单元，还用于在所述存储单元将所述业务短信存入所述緩存队列 后 ,判断所述緩存队列中的业务短信数量是否与所述业务短信中的子包总数字 段值一致；

   所述合并处理单元，用于当所述判断单元判断出所述緩存队列中的业务短 信数量与所述业务短信中的子包总数字段值一致时，依据所述緩存队列中所有 业务短信中的子包序号，将所述緩存队列中的所有业务短信的消息体内容合并 成原始业务数据后， 对所述原始业务数据进行处理；

   所述发送单元，用于当所述判断单元判断出所述緩存队列中的业务短信数 量与所述业务短信中的子包总数字段值不一致时，向所述业务应用服务器发送 子包重发短信，以指示所述业务应用服务器重新发送所述緩存队列中未包含的 业务短信。

   10、 根据权利要求 9所述的设备， 其特征在于，

   所述判断单元，还用于在判断出所述緩存队列中的业务短信数量与所述业 务短信中的子包总数字段值不一致时，判断在所述緩存队列存入第一条业务短 信时开始的计时是否超过预置的等待时间；

   所述发送单元，具体用于当所述判断单元判断出所述緩存队列中的业务短 信数量与所述业务短信中的子包总数字段值不一致，且在所述緩存队列存入第 一条业务短信时开始的计时超过预置的等待时间时，向所述业务应用服务器发 送子包重发短信。

   11、 根据权利要求 9或 10所述的设备， 其特征在于，

   所述判断单元，具体用于依据所述接收单元接收的业务短信中的分包标志 字段值判断所述业务短信是否为消息子包。

   12、 根据权利要求 9或 10所述的设备， 其特征在于，

   所述接收单元接收的业务短信中携带第一校验码；

   所述设备还包括： 运算单元和比较单元；

   所述运算单元，用于采用预定的校验算法对接收单元接收到的业务短信进 行运算， 得到第二校验码；

   所述比较单元，用于将所述第一校验码与所述运算单元得到的第二校验码 进行比较；

   所述发送单元，还用于在所述比较单元获得的的比较结果为不一致时， 向 所述业务应用服务器发送数据重发短信，以指示所述业务应用服务器重新发送 所述接收单元接收的业务短信。

   13、 根据权利要求 12所述的设备， 其特征在于，

   所述运算单元具体采用循环冗余校验算法对接收单元接收到的业务短信 14、 一种业务应用服务器， 其特征在于， 包括：

   生成单元， 用于生成业务短信， 在所述业务短信为消息子包时， 所述业务 短信包括消息序列号以及子包序号；

   发送单元， 用于向用户设备发送所述业务短信；

   接收单元， 用于接收所述用户设备发送的子包重发短信， 所述子包重发短 信包括需要重新发送的业务短信的消息序列号及子包序号；

   所述发送单元，还用于在所述接收单元接收到所述用户设备发送的子包重 发短信时， 向所述用户设备重新发送所述子包重发短信指示的业务短信。

   15、 根据权利要求 14所述的业务应用服务器， 其特征在于， 还包括： 运算单元，用于采用预定的校验算法对所述生成单元生成的业务短信进行 运算， 得到第一校验码， 将所述第一检验码携带在所述生成的业务短信中。

   16、 如权利要求 15所述的业务应用服务器， 其特征在于， 所述接收单元， 还用于接收所述用户设备发送的数据重发短信；

   所述发送单元，还用于在所述接收单元接收到用户设备发送的数据重发短 信时， 向所述用户设备重新发送所述数据重发短信中指示的业务短信。

   17、 一种短信业务***， 其特征在于， 包括：

   如权利要求 14至 16任一项所述的业务应用服务器， 和 /或包括如权利要 求 9至 13任一项所述的用户设备。