CN111083161A - 数据传输的处理方法及装置、物联网设备 - Google Patents

Abstract

本申请公开了一种数据传输的处理方法及装置、物联网设备。其中，该方法包括：对待传输数据采用预设通信协议进行封装，得到待传输数据对应的数据包，其中，预设通信协议包括：报文头部数据，待传输数据位于报文头部数据的末尾；确定数据包的长度；依据数据包的长度确定是否需要将数据包拆分成多个子数据包进行传输。本申请解决了现有的物联网通信协议无法实现分包传输、各厂家的通信协议标准不统一的技术问题。

Description

数据传输的处理方法及装置、物联网设备

技术领域

本申请涉及通信技术领域，具体而言，涉及一种数据传输的处理方法及装置、物联网设备。

背景技术

随着科技的进步以及5G通信技术的普及，物联网行业迎来了技术上的爆发，产业不断的发展，各种新产品、新技术不断涌现，还有一些新的领域被不断的纳入到这个范围，但发展到现在物联网领域还是有一些问题没有解决，这些问题随着时间不断地凸显出来。目前物联网同层级主流通信协议包括：消息队列遥测传输协议(Message QueuingTelemetry Transport，MQTT)、适用于资源有限的终端设备管理的轻量级物联网协议(Lightweight Machine to Machine，LWM2M)等。

现有物联网通信协议主要存在以下问题：

协议上无法实现分包传输，在部分在窄带通信技术上不宜传输大包数据，大包数据会降低传输的准确性及增加重传概率；

各厂家协议和标准不统一，目前的技术厂商都有自己的技术标准，这些标准都是自己使用和别的产品不兼容，一旦需要联合使用兼容性问题就很严重，有的即使进行了数据的兼容但因为逻辑和结构的问题，后续还会有些别的问题并发产生，很不利于物联网产品的发展和成长；

通信的架构和流程不合理，有些厂商的通信架构没有考虑好物联网的应用场景，协议设置的比较臃肿，造成大量的资源浪费，并且一些轻量级的设备没法实现这些比较耗费资源的协议，还有就是有的协议交互流程过于复杂，对于系统和网络要求比较多，造成适应性并不广；

很多的协议专业性过于的强，这些协议只针对专门的领域进行开发，别的领域使用起来非常的不方便，需要做出巨大的修改。

基于上述问题，现在需要一个统一的通信协议来规范各种物联网设备的通信，从而实现物联网的互联互通。

发明内容

本申请实施例提供了一种数据传输的处理方法及装置、物联网设备，以至少解决现有的物联网通信协议无法实现分包传输、各厂家的通信协议标准不统一的技术问题。

根据本申请实施例的一个方面，提供了一种数据传输的处理方法，包括：获取待传输数据；对待传输数据采用预设通信协议进行封装，得到待传输数据对应的数据包，其中，预设通信协议包括：报文头部数据，待传输数据位于报文头部数据的末尾；确定数据包的长度；依据数据包的长度确定是否需要将数据包拆分成多个子数据包进行传输。

可选地，报文头部数据至少包括如下字段：数据包序号，通信协议版本号、分包信息，设备的标识长度、设备的标识、待传输数据的请求类型以及Option数据，其中，分包信息包括数据包是否分包传输的信息，设备为依据预设通信协议进行通信的设备，Option数据包括描述待传输数据的参数。

可选地，在对待传输数据采用预设通信协议进行封装之前，上述方法还包括：初始化数据包序号，初始化通信协议版本号以及初始化数据包的重传次数。

可选地，上述预设通信协议还包括：Payload数据字段，对待传输数据采用预设通信协议进行封装，包括：将待传输数据存储在Payload数据字段。

可选地，上述预设通信协议还包括：报文头部数据结束符，报文头部数据结束符用于分隔报文头部数据和在Payload数据字段。

可选地，依据数据包的长度确定是否需要将数据包拆分成多个子数据包进行传输，包括：依据报文头部数据、报文头部数据结束符以及待传输数据的总长度确定是否需要将数据包拆分成多个子数据包进行传输，其中，如果总长度大于预设阈值，将数据包拆分成多个子数据包，多个子数据包中任意一个子数据包的长度小于或者等于预设阈值；如果总长度小于或等于预设阈值，拒绝将数据包拆分。

可选地，将数据包拆分成多个子数据包，包括：将待传输数据拆分成多个子数据，多个子数据的数量与多个子数据包的数量相同；分别将多个子数据中的每个子数据进行编号；依据每个子数据编号生成每个子数据对应的子数据包的报文头部数据。

可选地，确定是否需要将数据包拆分成多个子数据包进行传输之后，上述方法还包括：将待传输数据对应的数据包按照数据包序号依次传输至目标地址。

可选地，将待传输数据对应的数据包按照数据包序号依次传输至目标地址，包括：如果在预设时间内收到确认消息，将数据包序号加1，确认消息用于表征当前传输的数据包成功传输至目标地址；如果在预设时间内未收到确认消息，重新传输当前传输的数据包，并将重传次数加1。

可选地，如果当前传输的数据包的重传次数超过预设次数，确认当前传输的数据包传输失败，删除当前传输的数据包，并将数据包序号加1。

根据本申请实施例的另一方面，还提供了一种数据传输的处理装置，包括：获取模块，用于获取待传输数据；封装模块，用于对待传输数据采用预设通信协议进行封装，得到待传输数据对应的数据包，其中，预设通信协议包括：报文头部数据，待传输数据位于报文头部数据的末尾；确定模块，用于确定数据包的长度；判断模块，用于依据数据包的长度确定是否需要将数据包拆分成多个子数据包进行传输。

根据本申请实施例的另一方面，还提供了一种物联网设备，物联网设备运行以上的数据传输的处理方法。

根据本申请实施例的再一方面，还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行以上的数据传输的处理方法。

根据本申请实施例的再一方面，还提供了一种处理器，处理器用于运行存储在存储器中的程序，其中，程序运行时执行以上的处理方法。

在本申请实施例中，采用获取待传输数据；对待传输数据采用预设通信协议进行封装，得到待传输数据对应的数据包，其中，预设通信协议包括：报文头部数据，待传输数据位于报文头部数据的末尾；确定数据包的长度；依据数据包的长度确定是否需要将数据包拆分成多个子数据包进行传输的方式，从而实现了物联网设备之间通信数据的分包传输、为各厂商提供了一个统一的物联网通信协议标准的技术效果，进而解决了现有的物联网通信协议无法实现分包传输、各厂家的通信协议标准不统一技术问题。

附图说明

此处所说明的附图用来提供对本申请的进一步理解，构成本申请的一部分，本申请的示意性实施例及其说明用于解释本申请，并不构成对本申请的不当限定。在附图中：

图1是根据本申请实施例的一种数据传输的处理方法的流程图；

图2是根据本申请实施例的一种物联网通信协议的帧结构的示意图；

图3是根据本申请实施例的一种Option数据结构示意图；

图4是根据本申请实施例的一种数据传输的处理装置的结构图。

具体实施方式

为了使本技术领域的人员更好地理解本申请方案，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分的实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本申请保护的范围。

需要说明的是，本申请的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本申请的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

根据本申请实施例，提供了一种数据传输的处理方法的实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

图1是根据本申请实施例的一种数据传输的处理方法的流程图，如图1所示，该方法包括如下步骤：

步骤S102，获取待传输数据。

步骤S104，对待传输数据采用预设通信协议进行封装，得到待传输数据对应的数据包，其中，预设通信协议包括：报文头部数据，待传输数据位于报文头部数据的末尾。

根据本申请的一个可选的实施例，对待传输数据进行封装之前，需要待传输数据初始化为二进制数据。

步骤S106，确定数据包的长度。

步骤S108，依据数据包的长度确定是否需要将数据包拆分成多个子数据包进行传输。

通过上述步骤，可以实现物联网设备之间通信数据的分包传输、为各厂商提供了协议功能扩展的功能，从而实现了统一的物联网通信协议标准的技术效果。

根据本申请的一个可选的实施例，报文头部数据至少包括如下字段：数据包序号，通信协议版本号、分包信息，设备的标识长度、设备的标识、待传输数据的请求类型以及Option数据，其中，分包信息包括数据包是否分包传输的信息，设备为依据预设通信协议进行通信的设备，Option数据包括描述待传输数据的参数。

根据本申请的一个可选的实施例，上述预设通信协议还包括：Payload数据字段，对待传输数据采用预设通信协议进行封装，包括：将待传输数据存储在Payload数据字段。

可选地，上述预设通信协议还包括：报文头部数据结束符，报文头部数据结束符用于分隔报文头部数据和在Payload数据字段。

图2是根据本申请实施例的一种物联网通信协议的帧结构的示意图，如图2所示，通信协议整体由报文头部数据(Header)、报文头部数据结束符(Header End)和Payload三部分组成，其中，Header由数据包序号、通信协议版本号、分包信息、设备的标识长度、设备的标识、待传输数据的请求类型以及Option数据组成，每条封装完成的数据包必须包含Header，缺少Header，该数据包将无法解析，将被进行抛弃处理。

报文头部数据结束符(Header End)，在报文头部数据(Header)结束后使用，用于分隔报文头部数据(Header)和待传输数据。

Payload由TLV(Tag Code、Length、Value)及Payload Abstract组成。一个TLV由一组Tag Code、Length和Value组成。Payload Abstract从Payload数据进行处理获得作为检验使用。

下面分别对上述协议中的字段具体说明：

数据包号也称为业务流水号(Message ID)，是业务发起方定义的数据的序号，主要用来作为数据分包、数据回复和数据确认时使用。

通信协议版本号(Ver.ID)是指数据包使用协议的版本序号，比如可以用十六进制数字0x01表示版本协议的版本序号。

分包信息是指带传输的数据封装完成的数据包是否需要分包传输的相关信息，具体的，在本申请实施例中，若数据包超过传输协议的单包限制，则需要对数据包进行分包，分包信息所在的字段共8bit，该字段前bit位表示分包的总数，后4bit表示当前包得编号，所有分割的数据包按照顺序从1开始进行编号，没有分包情况下，该分包信息字段可以用一个特定值表示(例如0x17，二进制数为00010001)。图2中的PKC指分包数，PKI是指分包编号。

设备的标识(DeviceID)是直连设备唯一识别的编号，由一串字符构成，要保证全球唯一。设备的标识长度(DeviceID Length)是设备唯一标识字段所占的字节长度。

待传输数据的请求类型(Request Type)是指数据包的请求类型，主要包括：心跳、更新数据、获取下发指令、获取指定数据、请求确认、请求否认以及流向控制。下面对上述几种请求类型简单进行解释：

1)心跳：当设备没有任何数据传输时，设备要周期性的告知平台设备在线状态，这个过程的请求类型为心跳。

2)更新数据：设备与平台双向都会使用，既可以设备往平台发送数据(数据上传)，也可以平台往设备发送数据(数据下发)。

3)获取下发指令：一般由设备往平台发送，常用在HTTP请求中，告知平台返回下发数据。

4)获取指定数据：设备与平台双向都会使用，一般由设备往平台发送，也可以应用在平台往设备发送，告知对方需要哪些类型的数据。

5)请求确认：设备与平台双向都会使用，用于数据接收到后确认功能。

6)请求否认：设备与平台双向都会使用，用于数据未接收到后否认功能，告知对方接收失败重新传输。

图3是根据本申请实施例的一种Option数据结构示意图，如图3所示，Option数据(Option Data)内容主要描述Payload数据的相关参数，包括：指令数量、需要获取的Tag的信息等。

Option主要由指令数量(DGC)、每条指令TLV数量和Tag列表组。数据组数量(DGC)表示当前message有多少组数据或多少条指令，每组数据TLV数量表示每组数据或指令工包括几个TLV，Tag列表(Tag List)表示在“请求获取指定数据”时，告知对方需要哪些Tag作为回复的数据返回给消息的发送方。

Payload数据(Payload Data)为要传输的具有实际的数据，即上文中的待传输数据。Payload数据由多组TLV数据点和Payload摘要数据(Payload Abstract)组成，一组TLV数据可以理解为一条指令，一个数据包可以拥有多个数据组。TLV由一组Tag Code、Length和Value组成。Tag表示一个设备的属性编号，Length表示传输的value长度，Value表示数据内容。Payload摘要数据(Payload Abstract)从Payload数据进行处理，获取12Byte长度作为检验使用。

根据本申请的一个可选的实施例，在执行步骤S102之前，还需要初始化数据包序号，初始化通信协议版本号以及初始化数据包的重传次数。将初始化完成的数据添加报文头部数据对应的字段中。

根据本申请的一个可选的实施例，步骤S108通过以下方式实现：依据报文头部数据、报文头部数据结束符以及待传输数据的总长度确定是否需要将数据包拆分成多个子数据包进行传输，其中，如果总长度大于预设阈值，将数据包拆分成多个子数据包，多个子数据包中任意一个子数据包的长度小于或者等于预设阈值；如果总长度小于或等于预设阈值，拒绝将数据包拆分。

如果封装完成的数据包的字节长度大于规定的预设长度，将数据包进行拆分，否则直接传输封装完成的数据包。需要说明的是，拆分完成的子数据包的字节长需要小于上述规定的预设阈值。本申请实施例提供的通信协议支持分包，分包信息在报文头部数据中进行配置，分包数据全部接收完毕后平台会回复告知分包数据全部接收成功，若传输过程中出现丢包情况，平台不予回复，需要重新发送丢失的数据包。

根据本申请的一个可选的实施例，可以通过以下方式将待传输的数据包拆分成多个子数据包：将待传输数据拆分成多个子数据，多个子数据的数量与多个子数据包的数量相同；分别将多个子数据中的每个子数据进行编号；依据每个子数据编号生成每个子数据对应的子数据包的报文头部数据。

可选地，将待传输数据拆分成多个子数据，对拆分的子数据编号，依次生成子数据对应的报文头部数据，然后将子数据重新封装成数据包。

根据本申请的一个可选的实施例，步骤S108执行完成之后，将待传输数据对应的数据包按照数据包序号依次传输至目标地址。如果数据包需要拆分，将拆分之后的数据包依次传输至目标地址；如果数据包不需要拆分，直接将数据包传输至目标地址。

在本申请的一个可选的实施例中，可以通过以下方式将待传输数据对应的数据包按照数据包序号依次传输至目标地址：如果在预设时间内收到确认消息，将数据包序号加1，确认消息用于表征当前传输的数据包成功传输至目标地址；如果在预设时间内未收到确认消息，重新传输当前传输的数据包，并将重传次数加1。

启动定时任务，等待消息的反馈，收到反馈后代表成功，发送的序号加1；如果超时后还没有收到反馈，则会重新发送，重发次数加1。

根据本申请的一个可选的实施例，如果当前传输的数据包的重传次数超过预设次数，确认当前传输的数据包传输失败，删除当前传输的数据包，并将数据包序号加1。

如果重发次数达到上限(超过预设次数)，则认为消息发送失败，删除消息，发送的序号加1。

本申请提供的上述数据传输的处理方法可以实现以下技术效果：

解决了目前各厂商设备通信协议不一致的问题，通过使用统一的通信协议可以让更多类型和数量的设备连接和通信，实现更加丰富的物联网产品的搭配和组合，完善产品的种类和搭配，适应多样的场景需要。

轻量化协议的架构，使协议更加的简洁，流程更加的简便，在功能和结构合理的基础上，尽量使协议的整体更加的轻巧，方便在物联网环境中快速的传输，同时节省流量和带宽，实现更多设备的连接通讯。此外，协议的轻量化，协议整体结构简单，学习比较容易，使用比较方便，针对不同场景不同设备的开发也比较的方便，可以快速的实现；同时通信过程简洁流畅，耗时少、效率高，维护简单。

完善协议的安全机制，包含错误校验、分包和按顺序合并包、重传控制、协议版本控制、数据加密等，让整个协议更加的全面和完善，满足不同的通信的需要。在有限的硬件资源下完成部分关键内容加密。

图4是根据本申请实施例的一种数据传输的处理装置的结构图，如图4所示，该装置包括：

获取模块40，用于获取待传输数据。

封装模块42，用于对待传输数据采用预设通信协议进行封装，得到待传输数据对应的数据包，其中，预设通信协议包括：报文头部数据，待传输数据位于报文头部数据的末尾。

确定模块44，用于确定数据包的长度。

判断模块46，用于依据数据包的长度确定是否需要将数据包拆分成多个子数据包进行传输。

需要说明的是，图4所示实施例的优选实施方式可以参见图1所示实施例的相关描述，此处不再赘述。

根据本申请实施例还提供了一种物联网设备，该物联网设备运行以上的数据传输的处理方法。

根据本申请的一个可选的实施例上述物联网设备用于运行以下数据传输的处理方法：获取待传输数据；对待传输数据采用预设通信协议进行封装，得到待传输数据对应的数据包，其中，预设通信协议包括：报文头部数据，待传输数据位于报文头部数据的末尾；确定数据包的长度；依据数据包的长度确定是否需要将数据包拆分成多个子数据包进行传输。

本申请实施例还提供了一种存储介质，存储介质包括存储的程序，其中，在程序运行时控制存储介质所在设备执行以上的数据传输的处理方法。

存储介质用于存储执行以下功能的程序：获取待传输数据；对待传输数据采用预设通信协议进行封装，得到待传输数据对应的数据包，其中，预设通信协议包括：报文头部数据，待传输数据位于报文头部数据的末尾；确定数据包的长度；依据数据包的长度确定是否需要将数据包拆分成多个子数据包进行传输。

本申请实施例还提供了一种处理器，处理器用于运行存储在存储器中的程序，其中，程序运行时执行以上的处理方法。

处理器用于运行存储在存储器中的执行以下功能的程序：对待传输数据采用预设通信协议进行封装，得到待传输数据对应的数据包，其中，预设通信协议包括：报文头部数据，待传输数据位于报文头部数据的末尾；确定数据包的长度；依据数据包的长度确定是否需要将数据包拆分成多个子数据包进行传输。

上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

在本申请的上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

在本申请所提供的几个实施例中，应该理解到，所揭露的技术内容，可通过其它的方式实现。其中，以上所描述的装置实施例仅仅是示意性的，例如所述单元的划分，可以为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，单元或模块的间接耦合或通信连接，可以是电性或其它的形式。

所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。

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

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

以上所述仅是本申请的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (14)

1.一种数据传输的处理方法，其特征在于，包括：

获取待传输数据；

对所述待传输数据采用预设通信协议进行封装，得到所述待传输数据对应的数据包，其中，所述预设通信协议包括：报文头部数据，所述待传输数据位于所述报文头部数据的末尾；

确定所述数据包的长度；

依据所述数据包的长度确定是否需要将所述数据包拆分成多个子数据包进行传输。

2.根据权利要求1所述的方法，其特征在于，所述报文头部数据至少包括如下字段：

数据包序号，通信协议版本号、分包信息，设备的标识长度、设备的标识、所述待传输数据的请求类型以及Option数据，其中，所述分包信息包括所述数据包是否分包传输的信息，所述设备为依据所述预设通信协议进行通信的设备，所述Option数据包括描述所述待传输数据的参数。

3.根据权利要求2所述的方法，其特征在于，在对所述待传输数据采用预设通信协议进行封装之前，所述方法还包括：

初始化所述数据包序号，初始化所述通信协议版本号以及初始化所述数据包的重传次数。

4.根据权利要求1所述的方法，其特征在于，所述预设通信协议还包括：Payload数据字段，对所述待传输数据采用预设通信协议进行封装，包括：

将所述待传输数据存储在所述Payload数据字段。

5.根据权利要求4所述的方法，其特征在于，所述预设通信协议还包括：

报文头部数据结束符，所述报文头部数据结束符用于分隔所述报文头部数据和所述Payload数据字段。

6.根据权利要求5所述的方法，其特征在于，依据所述数据包的长度确定是否需要将所述数据包拆分成多个子数据包进行传输，包括：

依据所述报文头部数据、所述报文头部数据结束符以及所述待传输数据的总长度确定是否需要将所述数据包拆分成多个子数据包进行传输，其中，

如果所述总长度大于预设阈值，将所述数据包拆分成多个子数据包，所述多个子数据包中任意一个子数据包的长度小于或者等于所述预设阈值；

如果所述总长度小于或等于所述预设阈值，拒绝将所述数据包拆分。

7.根据权利要求6所述的方法，其特征在于，将所述数据包拆分成多个子数据包，包括：

将所述待传输数据拆分成多个子数据，所述多个子数据的数量与所述多个子数据包的数量相同；

分别将所述多个子数据中的每个子数据进行编号；

依据所述每个子数据编号生成所述每个子数据对应的子数据包的报文头部数据。

8.根据权利要求1至7中任意一项所述的方法，其特征在于，确定是否需要将所述数据包拆分成多个子数据包进行传输之后，所述方法还包括：

将所述待传输数据对应的数据包按照所述数据包序号依次传输至目标地址。

9.根据权利要求8所述的方法，其特征在于，将所述待传输数据对应的数据包按照所述数据包序号依次传输至目标地址，包括：

如果在预设时间内收到确认消息，将所述数据包序号加1，所述确认消息用于表征当前传输的数据包成功传输至所述目标地址；

如果在所述预设时间内未收到确认消息，重新传输当前传输的所述数据包，并将所述重传次数加1。

10.根据权利要求9所述的方法，其特征在于，如果当前传输的所述数据包的重传次数超过预设次数，确认当前传输的所述数据包传输失败，删除当前传输的所述数据包，并将所述数据包序号加1。

11.一种数据传输的处理装置，其特征在于，包括：

获取模块，用于获取待传输数据；

封装模块，用于对所述待传输数据采用预设通信协议进行封装，得到所述待传输数据对应的数据包，其中，所述预设通信协议包括：报文头部数据，所述待传输数据位于所述报文头部数据的末尾；

确定模块，用于确定所述数据包的长度；

判断模块，用于依据所述数据包的长度确定是否需要将所述数据包拆分成多个子数据包进行传输。

12.一种物联网设备，其特征在于，所述物联网设备运行权利要求1至10中任意一项所述的数据传输的处理方法。

13.一种存储介质，其特征在于，所述存储介质包括存储的程序，其中，在所述程序运行时控制所述存储介质所在设备执行权利要求1至10中任意一项所述数据传输的处理方法。

14.一种处理器，其特征在于，所述处理器用于运行存储在存储器中的程序，其中，所述程序运行时执行权利要求1至10中任意一项所述数据传输的处理方法。

Images