CN109525370A - 基于zigbee的数据包发送方法 - Google Patents

Abstract

本发明揭示了一种基于zigbee的数据包发送方法，包括如下步骤：S1、在处理分析***内对协议格式进行定义，得到自定义协议格式并将其下发至协调器及终端节点中；S2、终端节点使用自定义协议格式对所获取的数据进行前期处理、生成不同格式的数据包，随后将数据包发送至协调器中；S3、协调器使用自定义协议格式对所接收的数据包进行后期处理，随后将数据包转发至处理分析***。本发明可借助自定义协议格式对所需传输的数据包大小进行判断，并依据判断结果对数据包进行相应的处理。不但能降低数据传输的时间及功耗，而且保证了***处理效率。

Description

基于zigbee的数据包发送方法

技术领域

本发明涉及一种数据包发送方法，具体而言，涉及一种克减少数据包大小、缩短发送时间的基于zigbee的数据包发送方法，属于计算机数据传输领域。

背景技术

Zigbee是一种短距离、低功耗的无线局域网通讯技术，相对于蓝牙、WI-FI等短距离无线通讯技术，Zigbee的功耗和使用成本更低，且具有自组网特性，因此这一技术目前被广泛应用于物联网和医疗设备等领域。

具体而言，Zigbee组网是将协调器、路由器和终端节点等节点组成的一个大的无线网络，其中，协调器和终端节点必不可少。协调器是网络中心节点，通常用于接收所有终端节点数据并转发到其他网络***。终端节点一般是处理业务采集和传输业务数据的节点，由于应用环境等原因终端节点通常都尺寸比较小，采用电池供电。

由于Zigbee的传输速率较低，在我国使用的2.4G频段链路上其传输效率仅有250Kb/s，因此一般只适用于数据传输速率低或数据量少的应用场景中。在单个终端节点需要传输大量数据的情况下，其传输效率就会变得很长，功耗也会随之增大。

综上所述，如何在现有技术的基础上提出一种新的数据传输方法，充分利用Zigbee的低功耗和易组网等特性，在保证传输时间及功耗的前提下完成较大数据包的传输，也就成为了本领域内技术人员亟待解决的问题。

发明内容

鉴于现有技术存在上述缺陷，本发明提出了一种基于zigbee的数据包发送方法，运行于zigbee网络中，所述zigbee网络包括处理分析***、协调器及终端节点，终端节点通过协调器与处理分析***交互连接，其特征在于，包括如下步骤：

S1、在处理分析***内对协议格式进行定义，得到自定义协议格式并将其下发至协调器及终端节点中；

S2、终端节点使用自定义协议格式对所获取的数据进行前期处理、生成不同格式的数据包，随后将数据包发送至协调器中；

S3、协调器使用自定义协议格式对所接收的数据包进行后期处理，随后将数据包转发至处理分析***。

优选地，所述终端节点包括大数据压缩终端节点、多帧明文终端节点及普通单帧终端节点中的任一一种或多种的组合。

优选地，所述自定义协议格式为：所有数据包的起始为两字节的数据包标识，随后按序依次为数据包头和数据包内容，所述数据包头和数据包内容二者均与数据包自身的格式相关；

所述数据包标识具体为16进制的数据FDFE。

优选地，S2中所述终端节点使用自定义协议格式对所获取的数据进行前期处理、生成不同格式的数据包，具体包括如下步骤：

当数据较大且数据总帧数大于1时，根据终端节点的处理能力决定是否对数据包进行压缩处理，

若此时终端节点有数据压缩能力，则对数据进行压缩处理，压缩后生成的数据包根据其长度是否可以一次发送、分为压缩多帧数据包和压缩单帧数据包，

若此时终端节点没有数据压缩处理能力，则生成非压缩明文多帧数据包；

当数据较小且可以一次发送时，生成非压缩明文单帧数据包。

优选地，所述对数据包进行压缩处理时，压缩方法为deflate压缩算法。

优选地，所述压缩多帧数据包的格式为：起始为两字节的数据包标识，随后按序依次为四字节的压缩标志，四字节的数据总长度、两字节的总帧数、两字节的当前帧数、两字节的本帧长度以及具体的压缩后的数据内容，最后为两字节的CRC16校验位；

所述压缩标志具体为16进制的数据FEFDEEDD。

优选地，所述压缩单帧数据包的格式为：起始为两字节的数据包标识，随后按序依次为四字节的压缩标志，四字节的数据总长度、两字节且内容固定为1的总帧数以及具体的压缩后的数据内容，最后为两字节的CRC16校验位；

所述压缩标志具体为16进制的数据FEFDEEDD。

优选地，所述非压缩明文多帧数据包的格式为：起始为两字节的数据包标识、随后按序依次为四字节的数据总长度、两字节的总帧数、两字节的当前帧数、两字节的本帧长度以及具体的数据内容，最后为两字节的CRC16校验位；

在所述非压缩明文多帧数据包中，所述数据总长度小于2³¹-1。

优选地，所述非压缩明文单帧数据包的格式为：起始为两字节的数据包标识、随后按序依次为四字节的数据总长度、数值固定为1的两字节的总帧数以及具体的数据内容，最后为两字节的CRC16校验位。

优选地，S3中所述协调器使用自定义协议格式对所接收的数据包进行后期处理，具体包括如下步骤：

S21、读取数据包起始的两个字节，判断数据包起始的两个字节是否为标识开头，是则进入下一步骤，否则将该数据包视为无效包、进行丢弃处理并读取下一数据包；

S22、再读取数据包内、后续的四个字节的数据，判断该四个字节的数据是否为压缩标志，

若是压缩标志，则标明该数据包为压缩数据包，再继续读取四个字节的数据作为数据总长度，继续进入下一步骤，

若不是压缩标志，则把该四个字节的数据作为数据总长度，判断数据总长度是否小于2³¹-1，如果小于则进入下一步骤，否则认为该数据包为无效包，进行丢弃处理并读取下一数据包，

所述数据总长度为不包含帧头信息和校验位的纯数据长度；

S23、读取数据总长度后续的两个字节的数据作为总帧数，随后判断总帧数是否小于1，如果小于则将该数据包视为无效包、进行丢弃处理，否则进入下一步骤；

S24、判断S23中所标明的压缩多帧数据包的总帧数是否大于1，

若大于1，则读取两个字节的数据做为当前帧数，随后在当前帧数后再读取两个字节的数据作为本帧长度；

若等于1，则直接进入进入下一步骤；

S25、读取数据包内具体的数据内容；

S26、读取数据包最后两个字节的校验码，并使用S25中读取的具体的数据内容、使用CRC16算法计算标准校验码，随后比较所读取的校验码与计算所得的标准校验码是否相同，是则进入下一步骤，否该数据包视为无效包、进行丢弃处理；

S27、依据上述步骤结果，对数据包格式进行明确判断，

若S24中判断数据总帧数为1，则直接对数据包内容进行是否压缩判断处理，

若S24中判断数据总帧数大于1，则标明数据为多帧数据，依据当前帧数作为序号顺序对数据按序进行拼接处理，在所有的数据帧都拼接完成后，再对数据是否为压缩数据进行判断，

若数据为压缩数据，则先对该数据包进行解压，随后将其转发至处理分析***，

若数据为非压缩数据，则直接将该数据包转发至处理分析***。

与现有技术相比，本发明的优点主要体现在以下几个方面：

本发明可借助自定义协议格式对所需传输的数据包大小进行判断，并依据判断结果对数据包进行相应的处理。当数据包较大时，对数据进行压缩、减少数据包的大小，进而降低数据传输的时间及功耗。当数据包较小时，则不做压缩处理，从而保证***处理效率。

此外，本发明也为同领域内的其他相关问题提供了参考，可以以此为依据进行拓展延伸，运用于同领域内其他使用zigbee技术的数据传输方案中，具有十分广阔的应用前景。

以下便结合实施例附图，对本发明的具体实施方式作进一步的详述，以使本发明技术方案更易于理解、掌握。

附图说明

图1为使用本发明的Zigbee网络示意图；

图2为本发明中压缩多帧数据包的结构示意图；

图3为本发明中压缩单帧数据包的结构示意图；

图4为本发明中非压缩明文多帧数据包的结构示意图；

图5为本发明中非压缩明文单帧数据包的结构示意图。

具体实施方式

本发明揭示了一种基于zigbee的数据包发送方法，运行于zigbee网络中。

所述zigbee网络的结构如图1所示，包括处理分析***、协调器及终端节点，终端节点通过协调器与处理分析***交互连接。本发明的方法，其原理在于，当数据包比较大时，需要对数据包进行分帧拆包发送处理，根据终端节点的处理能力和软硬件平台情况，可以对数据进行压缩，也可以不压缩，当数据包比较小、可以在一帧内处理时，则不对数据进行拆包和压缩处理。

所述终端节点包括大数据压缩终端节点、多帧明文终端节点及普通单帧终端节点中的任一一种或多种的组合，具体的设置情况可以依据实际的使用需要进行选择。而为了保证zigbee网络的正常使用，其中的协调器则必须同时支持多数据包格式的识别和处理。

本发明的基于zigbee的数据包发送方法，具体包括如下步骤：

S1、在处理分析***内对协议格式进行定义，得到自定义协议格式并将其下发至协调器及终端节点中；

S2、终端节点使用自定义协议格式对所获取的数据进行前期处理、生成不同格式的数据包，随后将数据包发送至协调器中；

S3、协调器使用自定义协议格式对所接收的数据包进行后期处理，随后将数据包转发至处理分析***。

为了支持多种数据包格式，本发明提出了一种自定义协议格式，该自定义协议格式可以简单明了的标明每一个数据包的格式，然后协调器或终端节点可以根据数据包的格式进行处理。

所述自定义协议格式为：所有数据包的起始为两字节的数据包标识，随后按序依次为数据包头和数据包内容，所述数据包头和数据包内容二者均与数据包自身的格式相关。所述数据包标识具体为16进制的数据FDFE。

S2中所述终端节点使用自定义协议格式对所获取的数据进行前期处理、生成不同格式的数据包，具体包括如下步骤：

当数据较大且数据总帧数大于1时，根据终端节点的处理能力决定是否对对数据包进行压缩处理。

若此时终端节点有数据压缩能力，则对数据进行压缩处理，压缩后生成的数据包根据其长度是否可以一次发送、分为压缩多帧数据包和压缩单帧数据包。

本实施例中所使用的压缩方法为deflate压缩算法。这是一种在计算机和嵌入式设备上广泛使用的无损压缩算法，有非常成熟的应用场景和实现代码。此外，还可以使用其他种类的压缩方法。

若此时终端节点没有数据压缩处理能力，则生成非压缩明文多帧数据包。

当数据较小且可以一次发送时，生成非压缩明文单帧数据包。

所述压缩多帧数据包的结构如图2所示，具体格式为：起始为两字节的数据包标识，随后按序依次为四字节的压缩标志，四字节的数据总长度、两字节的总帧数、两字节的当前帧数、两字节的本帧长度以及具体的压缩后的数据内容，最后为两字节的CRC16校验位；所述压缩标志具体为16进制的数据FEFDEEDD。

所述压缩单帧数据包的结构如图3所示，具体格式为：起始为两字节的数据包标识，随后按序依次为四字节的压缩标志，四字节的数据总长度、两字节且内容固定为1的总帧数以及具体的压缩后的数据内容，最后为两字节的CRC16校验位；所述压缩标志具体为16进制的数据FEFDEEDD。

所述非压缩明文多帧数据包的结构如图4所示，具体格式为：起始为两字节的数据包标识、随后按序依次为四字节的数据总长度、两字节的总帧数、两字节的当前帧数、两字节的本帧长度以及具体的数据内容，最后为两字节的CRC16校验位；在所述非压缩明文多帧数据包中，所述数据总长度小于2³¹-1。

所述非压缩明文单帧数据包的结构如图5所示，具体格式为：起始为两字节的数据包标识、随后按序依次为四字节的数据总长度、数值固定为1的两字节的总帧数以及具体的数据内容，最后为两字节的CRC16校验位。在本实施例中，在对单帧数据包进行处理时，无需进行压缩。

本发明中多种数据包的结尾均设置有CRC16校验位，主要是为了用于避免数据包内的数据错误。

S3中所述协调器使用自定义协议格式对所接收的数据包进行后期处理，具体包括如下步骤：

S21、读取数据包起始的两个字节，判断数据包起始的两个字节是否为标识开头，是则进入下一步骤，否则将该数据包视为无效包、进行丢弃处理并读取下一数据包。

S22、再读取数据包内、后续的四个字节的数据，判断该四个字节的数据是否为压缩标志，

若是压缩标志，则标明该数据包为压缩数据包，再继续读取四个字节的数据作为数据总长度，继续进入下一步骤，

若不是压缩标志，则把该四个字节的数据作为数据总长度，判断数据总长度是否小于2³¹-1，如果小于则进入下一步骤，否则认为该数据包为无效包，进行丢弃处理并读取下一数据包，

所述数据总长度为不包含帧头信息和校验位的纯数据长度。

S23、读取数据总长度后续的两个字节的数据作为总帧数，随后判断总帧数是否小于1，如果小于则将该数据包视为无效包、进行丢弃处理，否则进入下一步骤。

S24、判断S23中所标明的压缩多帧数据包的总帧数是否大于1，

若大于1，则读取两个字节的数据做为当前帧数，随后在当前帧数后再读取两个字节的数据作为本帧长度。

若等于1，则直接进入进入下一步骤。

S25、读取数据包内具体的数据内容。

S26、读取数据包最后两个字节的校验码，并使用S25中读取的具体的数据内容、使用CRC16算法计算标准校验码，随后比较所读取的校验码与计算所得的标准校验码是否相同，是则进入下一步骤，否该数据包视为无效包、进行丢弃处理。

S27、依据上述步骤结果，对数据包格式进行明确判断，

若S24中判断数据总帧数为1，则直接对数据包内容进行是否压缩判断处理，

若S24中判断数据总帧数大于1，则标明数据为多帧数据，依据当前帧数作为序号顺序对数据按序进行拼接处理，在所有的数据帧都拼接完成后，再对数据是否为压缩数据进行判断，

若数据为压缩数据，则先对该数据包进行解压，随后将其转发至处理分析***，

若数据为非压缩数据，则直接将该数据包转发至处理分析***。

需要说明的是，在实际的使用过程中，本发明可以有多种变化方式，诸如：数据包起始的标识开头可以不是两个字节、可以是其他内容或长度，也可以没有标识开头。同理，数据长度也可以是两字节，这样的设置适用于不是太大的数据包；压缩标志可以是其他内容和长度；总帧数、当前帧数、和本帧长度可以是1字节或其他长度表示；校验位可以是1字节、4字节或其他长度，也可以是CRC之外的其他算法等。

本发明可充分利用zigbee网络，实现对硬件资源的合理利用，具有很强的实用性和适用性。同时，本发明借助自定义协议格式对所需传输的数据包大小进行判断，并依据判断结果对数据包进行相应的处理。当数据包较大时，对数据进行压缩、减少数据包的大小，进而降低数据传输的时间及功耗。当数据包较小时，则不做压缩处理，从而保证***处理效率。

此外，本发明也为同领域内的其他相关问题提供了参考，可以以此为依据进行拓展延伸，运用于同领域内其他使用zigbee技术的数据传输方案中，具有十分广阔的应用前景。

对于本领域技术人员而言，显然本发明不限于上述示范性实施例的细节，而且在不背离本发明的精神和基本特征的情况下，能够以其他的具体形式实现本发明。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本发明的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本发明内，不应将权利要求中的任何附图标记视为限制所涉及的权利要求。

此外，应当理解，虽然本说明书按照实施方式加以描述，但并非每个实施方式仅包含一个独立的技术方案，说明书的这种叙述方式仅仅是为清楚起见，本领域技术人员应当将说明书作为一个整体，各实施例中的技术方案也可以经适当组合，形成本领域技术人员可以理解的其他实施方式。

Claims (10)

1.一种基于zigbee的数据包发送方法，运行于zigbee网络中，所述zigbee网络包括处理分析***、协调器及终端节点，终端节点通过协调器与处理分析***交互连接，其特征在于，包括如下步骤：

S1、在处理分析***内对协议格式进行定义，得到自定义协议格式并将其下发至协调器及终端节点中；

S2、终端节点使用自定义协议格式对所获取的数据进行前期处理、生成不同格式的数据包，随后将数据包发送至协调器中；

S3、协调器使用自定义协议格式对所接收的数据包进行后期处理，随后将数据包转发至处理分析***。

2.根据权利要求1所述的基于zigbee的数据包发送方法，其特征在于：所述终端节点包括大数据压缩终端节点、多帧明文终端节点及普通单帧终端节点中的任一一种或多种的组合。

3.根据权利要求1所述的基于zigbee的数据包发送方法，其特征在于，所述自定义协议格式为：所有数据包的起始为两字节的数据包标识，随后按序依次为数据包头和数据包内容，所述数据包头和数据包内容二者均与数据包自身的格式相关；

所述数据包标识具体为16进制的数据FDFE。

4.根据权利要求3所述的基于zigbee的数据包发送方法，其特征在于，S2中所述终端节点使用自定义协议格式对所获取的数据进行前期处理、生成不同格式的数据包，具体包括如下步骤：

当数据较大且数据总帧数大于1时，根据终端节点的处理能力决定是否对数据包进行压缩处理，

若此时终端节点有数据压缩能力，则对数据进行压缩处理，压缩后生成的数据包根据其长度是否可以一次发送、分为压缩多帧数据包和压缩单帧数据包，

若此时终端节点没有数据压缩处理能力，则生成非压缩明文多帧数据包；

当数据较小且可以一次发送时，生成非压缩明文单帧数据包。

5.根据权利要求4所述的基于zigbee的数据包发送方法，其特征在于：所述对数据包进行压缩处理时，压缩方法为deflate压缩算法。

6.根据权利要求4所述的基于zigbee的数据包发送方法，其特征在于，所述压缩多帧数据包的格式为：起始为两字节的数据包标识，随后按序依次为四字节的压缩标志，四字节的数据总长度、两字节的总帧数、两字节的当前帧数、两字节的本帧长度以及具体的压缩后的数据内容，最后为两字节的CRC16校验位；

所述压缩标志具体为16进制的数据FEFDEEDD。

7.根据权利要求4所述的基于zigbee的数据包发送方法，其特征在于，所述压缩单帧数据包的格式为：起始为两字节的数据包标识，随后按序依次为四字节的压缩标志，四字节的数据总长度、两字节且内容固定为1的总帧数以及具体的压缩后的数据内容，最后为两字节的CRC16校验位；

所述压缩标志具体为16进制的数据FEFDEEDD。

8.根据权利要求4所述的基于zigbee的数据包发送方法，其特征在于，所述非压缩明文多帧数据包的格式为：起始为两字节的数据包标识、随后按序依次为四字节的数据总长度、两字节的总帧数、两字节的当前帧数、两字节的本帧长度以及具体的数据内容，最后为两字节的CRC16校验位；

在所述非压缩明文多帧数据包中，所述数据总长度小于2³¹-1。

9.根据权利要求4所述的基于zigbee的数据包发送方法，其特征在于，所述非压缩明文单帧数据包的格式为：起始为两字节的数据包标识、随后按序依次为四字节的数据总长度、数值固定为1的两字节的总帧数以及具体的数据内容，最后为两字节的CRC16校验位。

10.根据权利要求4所述的基于zigbee的数据包发送方法，其特征在于，S3中所述协调器使用自定义协议格式对所接收的数据包进行后期处理，具体包括如下步骤：

S21、读取数据包起始的两个字节，判断数据包起始的两个字节是否为标识开头，是则进入下一步骤，否则将该数据包视为无效包、进行丢弃处理并读取下一数据包；

S22、再读取数据包内、后续的四个字节的数据，判断该四个字节的数据是否为压缩标志，

若是压缩标志，则标明该数据包为压缩数据包，再继续读取四个字节的数据作为数据总长度，继续进入下一步骤，

若不是压缩标志，则把该四个字节的数据作为数据总长度，判断数据总长度是否小于2³¹-1，如果小于则进入下一步骤，否则认为该数据包为无效包，进行丢弃处理并读取下一数据包，

所述数据总长度为不包含帧头信息和校验位的纯数据长度；

S23、读取数据总长度后续的两个字节的数据作为总帧数，随后判断总帧数是否小于1，如果小于则将该数据包视为无效包、进行丢弃处理，否则进入下一步骤；

S24、判断S23中所标明的压缩多帧数据包的总帧数是否大于1，

若大于1，则读取两个字节的数据做为当前帧数，随后在当前帧数后再读取两个字节的数据作为本帧长度；

若等于1，则直接进入进入下一步骤；

S25、读取数据包内具体的数据内容；

S26、读取数据包最后两个字节的校验码，并使用S25中读取的具体的数据内容、使用CRC16算法计算标准校验码，随后比较所读取的校验码与计算所得的标准校验码是否相同，是则进入下一步骤，否该数据包视为无效包、进行丢弃处理；

S27、依据上述步骤结果，对数据包格式进行明确判断，

若S24中判断数据总帧数为1，则直接对数据包内容进行是否压缩判断处理，

若S24中判断数据总帧数大于1，则标明数据为多帧数据，依据当前帧数作为序号顺序对数据按序进行拼接处理，在所有的数据帧都拼接完成后，再对数据是否为压缩数据进行判断，

若数据为压缩数据，则先对该数据包进行解压，随后将其转发至处理分析***，

若数据为非压缩数据，则直接将该数据包转发至处理分析***。