CN107579863A - 终端ota升级方法、装置及系统 - Google Patents

Abstract

本申请实施例提供一种终端OTA升级方法、装置及系统。其中，网管服务器通过一标识地址和地址掩码来标识需要进行固件升级的待升级终端；通过下发OTA升级命令并在OTA升级命令中携带统一的升级启动时间，使得待升级终端可以在升级启动时间到达时，统一唤醒并在广播信道上接收网管服务器分发的固件升级包进行固件升级。因此，本申请实施例可以对待升级终端进行批量升级，可缩短终端OTA升级时间，提高升级效率。

Description

终端OTA升级方法、装置及系统

技术领域

本申请涉及低功耗广域网技术领域，尤其涉及一种终端OTA升级方法、装置及系统。

背景技术

为了满足物联网对于广范围、远距离无线通信的要求，低功耗广域网(Low PowerWide Area Network，LPWAN)技术应运而生。LPWAN一般由网管服务器、物联网平台、物联网基站和物联网终端组成。LPWAN物联网终端在运行中需要根据实际需求进行固件升级，以满足新增用户的需求或固件版本修复。

空中下载(Over the Air，OTA)技术是一种通过空中无线射频信号为终端设备分发新软件、新配置的技术，被广泛应用于对LPWAN的物联网终端进行固件升级。在现有技术中，一般由物联网基站对其覆盖范围内的物联网终端逐个进行OTA升级，终端升级耗费时间长，升级效率低。

发明内容

本申请的多个方面提供一种终端OTA升级方法、装置及系统，用于按需实现物联网终端的批量升级，提高终端升级效率。

本申请实施例提供一种终端OTA升级方法，应用于第一终端，包括：

接收网管服务器下发的OTA升级命令，所述OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间；

根据所述待升级终端的标识地址和所述地址掩码，确定所述第一终端属于所述待升级终端；

在所述升级启动时间到达时，在所述广播信道上接收所述网管服务器分发的固件升级包；

根据所述固件升级包进行固件升级。

本申请实施例还提供一种终端OTA升级方法，应用于网管服务器，包括：

根据升级需求，获取待升级终端的标识地址和地址掩码；

向所述待升级终端广播OTA升级命令，所述OTA升级命令包括所述待升级终端的标识地址、地址掩码以及升级启动时间；

在所述升级启动时间到达时，通过所述广播信道向所述待升级终端分发固件升级包，以供所述待升级终端接收所述固件升级包并进行升级。

本申请实施例还提供一种终端，包括：第一接收模块，用于接收网管服务器下发的OTA升级命令，所述OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间；

确定模块，用于根据所述待升级终端的标识地址和所述地址掩码，确定所述终端属于所述待升级终端；

第二接收模块，用于在所述升级启动时间到达时，在所述广播信道上接收所述网管服务器分发的固件升级包；

升级模块，用于根据所述固件升级包进行固件升级。

本申请实施例还提供一种网管服务器，包括：获取模块，用于根据升级需求，获取待升级终端的标识地址和地址掩码；

下发模块，用于向所述待升级终端下发OTA升级命令，所述OTA升级命令包括所述待升级终端的标识地址、地址掩码以及升级启动时间；

分发模块，用于在所述升级启动时间到达时，通过所述广播信道向所述待升级终端分发固件升级包，以供所述待升级终端接收所述固件升级包并进行升级。

本申请实施例还提供一种OTA升级系统，包括上述实施例提供的终端和上述实施例提供的网管服务器。

在本申请实施例中，网管服务器通过一标识地址和地址掩码来标识需要进行固件升级的待升级终端；通过下发OTA升级命令并在OTA升级命令中携带统一的升级启动时间，使得待升级终端可以在升级启动时间到达时，统一唤醒并在广播信道上接收网管服务器分发的固件升级包进行固件升级。由此可见，本申请实施例可以对待升级终端进行批量升级，可缩短终端OTA升级时间，提高升级效率。

附图说明

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

图1a为本申请一实施例提供的一种终端OTA升级系统的结构示意图；

图1b为本申请一实施例提供的一种物联网系统的结构示意图；

图2为本申请一实施例提供的一种终端OTA升级方法的流程示意图；

图3a为本申请一实施例提供的另一种终端OTA升级方法的流程示意图；

图3b为本申请一实施例提供的一种固件升级包的格式示意图；

图4为本申请一实施例提供的又一种终端OTA升级方法的流程示意图；

图5a为本申请一实施例提供的又一种终端OTA升级方法的流程示意图；

图5b为本申请一实施例提供的一种固件升级包分片报文的格式示意图；

图5c为本申请一实施例提供的一种位图文件结构示意图；

图5d为本申请一实施例提供的一种缺失分片请求报文的格式示意图；

图6a为本申请另一实施例提供的一种终端OTA升级方法的流程示意图；

图6b为本申请另一实施例提供的一种终端Flash存储空间划分结构示意图；

图7为本申请又一实施例提供的一种终端OTA升级方法的流程示意图；

图8为本申请又一实施例提供的另一种终端OTA升级方法的流程示意图；

图9为本申请又一实施例提供的终端OTA升级准备阶段交互流程示意图；

图10为本申请又一实施例提供的终端OTA升级执行阶段交互流程示意图；

图11为本申请又一实施例提供的一种终端的结构示意图；

图12为本申请又一实施例提供的一种网管服务器的结构示意图。

具体实施方式

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

针对现有终端OTA升级耗费时间长、升级效率低的问题，本申请实施例提供一种解决方案，主要原理是：网管服务器通过待升级终端的标识地址和地址掩码来标识需要进行固件升级的待升级终端，并设置升级启动时间来控制待升级终端统一在广播信道上接收网管服务器分发的固件升级包，可以实现待升级终端的批量升级，有利于缩短终端OTA升级时间，提高升级效率。

以下结合附图，详细说明本申请各实施例提供的技术方案。

图1为本申请一实施例提供的一种终端OTA升级系统的结构示意图。该系统可应用于LPWAN网络，但不限于此。如图1所示，该系统10a包括：至少一台终端11以及网管服务器12。

至少一台终端11主要用于在所属应用场景中监测有关事件并进行相关处理。在不同的应用场景中，终端11对监测到的事件的处理方式会有所不同。例如，在一些应用场景中，当监测到相关事件发生时，终端11可以通过网络将事件上报给网管服务器12以供网管服务器12进行相应处理。网管服务器12主要用于接收终端11上报的有关事件并针对有关事件进行相应处理。在不同的应用场景中，网管服务器12根据终端11上报的事件进行相应处理的方式也会有所不同。

例如，当终端11监测到自身被唤醒时，可以将其唤醒状态上报给网管服务器12；网管服务器12可以在终端11处于唤醒状态时向终端11下发有关数据。

在实际运行过程中，当终端11的版本升级或终端11的固件存在缺陷需要修复时，网管服务器12可以采用OTA方式对终端11进行固件升级，简称为OTA升级。基于此，网管服务器12还用于控制终端11进行OTA升级。相应地，终端11还会在网管服务器12的控制下进行固件升级。

考虑到终端11的数量一般较多，大多数情况下需要针对多个终端11进行OTA升级，为了节约整体升级时间，提高整体升级效率，网管服务器12采用广播方式对终端11进行批量升级，而不是对每个终端11单独进行升级。

一方面，为了对终端11进行批量升级，网管服务器12通过标识地址和地址掩码相结合的方式来灵活标识需要升级的终端，需要升级的终端可以是至少一个终端11中的部分，也可以是至少一个终端11中的全部。为简化描述，本申请实施例中有些地方会将需要升级的终端11称为待升级终端。这里的标识地址主要用于标识待升级终端，待升级终端可以是一个或多个。

另一方面，为了对终端11进行批量升级，需要向待升级终端统一下发固件升级包。为此，网管服务器12通过设置升级启动时间要求待升级终端设备能够在统一时间监听广播信道，为统一下发固件升级包打下基础。

基于上述，网管服务器12可以根据升级需求，获取待升级终端的标识地址和地址掩码，并确定升级启动时间，然后将待升级终端的标识地址、地址掩码以及升级启动时间携带在OTA升级命令中，之后将该OTA升级命令下发给待升级终端。

在一可选实施方式中，上述升级需求包括待升级终端的标识地址和地址掩码。基于此，网管服务器12可以直接从升级需求中获取待升级终端的标识地址和地址掩码。

在一可选实施方式中，上述升级需求包括待升级终端的描述信息，例如待升级终端所属终端组、待升级终端负责的业务类型等，这些描述信息可唯一确定待升级终端。基于此，网管服务器12可以根据该描述信息计算出待升级终端的标识地址和地址掩码。

对任一终端11来说，在唤醒时，可在下行数据接收窗口打开期间接收网管服务器12下发的OTA升级命令，根据该OTA升级命令中的标识地址和地址掩码，确定自身是否属于待升级终端。例如，以至少一个终端11中的第一终端为例，第一终端可以将自身的设备地址与该OTA升级命令中的地址掩码进行与操作，并判断与操作的结果是否与该OTA升级命令中的标识地址相同；若与操作的结果与该OTA升级命令中的标识地址相同，确定第一终端属于待升级终端。其中，第一终端是至少一个终端11中任意终端。可选地，在LPWAN中，第一终端的设备地址可以简称为DEVADDR。

当升级启动时间到达时，网管服务器12会通过广播信道向待升级终端分发固件升级包，以便控制待升级终端进行批量升级。相应地，至少一个终端11中的待升级终端也会在升级启动时间到达时在广播信道上接收网管服务器12分发的固件升级包，并根据接收到的固件升级包进行固件升级。

由此可见，在本实施例提供的系统中，网管服务器通过待升级终端的标识地址和地址掩码来标识需要进行固件升级的待升级终端，并设置升级启动时间来控制待升级终端统一在广播信道上接收网管服务器分发的固件升级包，可以实现终端的批量升级，有利于缩短终端OTA升级时间，提高升级效率。

在一可选实施例中，图1a所示系统10可实现为物联网系统。如图1b所示，该物联网系统10b除了包括至少一个终端11和网管服务器12之外，还包括至少一个物联网基站13和物联网平台14。其中，物联网平台14连接于网管服务器12和至少一个物联网基站13之间。

物联网基站13通过局域网(Local Area Network，LAN)、3G或4G网络接入物联网平台14，并为其覆盖范围内的终端11提供接入服务。另外，物联网基站13主要用于在物联网平台14与其覆盖范围内的终端11之间进行数据透传，即将来自物联网平台14的下行数据转发给相应的终端11，并将来自终端11的数据上报给物理网平台14，在此过程中不对数据进行任何修改。

物联网平台14主要提供物联网基站13和网管服务器12之间的接入接口，并用于进行数据的转发、协议转换等，还可用于在终端11处于休眠状态时临时缓存网管服务器12下发给终端11的数据，比如OTA升级命令。

下面实施例将分别从终端和网管服务器的角度对本申请实施例提供的OTA升级方法的流程进行描述。其中，对任一终端来说，其进行OTA升级的流程均相同，故在下述方式实施例中以其中任一终端为例进行说明，为便于描述和区分将该终端记为第一终端。

图2为本申请一实施例提供的一种终端OTA升级方法的流程示意图，应用于第一终端，如图2所示，该方法包括：

201、接收网管服务器下发的OTA升级命令，该OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间。

202、根据待升级终端的标识地址和地址掩码，确定第一终端属于待升级终端。

203、在升级启动时间到达时，在广播信道上接收网管服务器分发的固件升级包。

204、根据固件升级包进行固件升级。

本实施例中，对于终端OTA升级系统中的所有终端来说，有的需要升级，有的不需要升级，网管服务器下发OTA升级命令，系统中的任意终端在唤醒时，下行数据接收窗口打开，并在此窗口打开期间都可以接收该OTA升级命令。其中，OTA升级命令中的待升级终端的标识地址和地址掩码，可以供终端确定是否属于待升级终端。OTA升级命令中的升级启动时间，可供待升级终端确定升级时间。

对于第一终端来说，有可能需要升级，也有可能不需要升级。当第一终端接收到该OTA升级命令后，可根据待升级终端的标识地址和地址掩码，并结合第一终端自身的设备地址，确定第一终端是否需要进行升级。当第一终端确定自身属于待升级终端时，可在升级启动时间到达时，在广播信道上接收网管服务器分发的固件升级包，以便根据固件升级包进行升级。其中，升级启动时间可以理解为网管服务器通知第一终端进行升级启动的时间，升级启动时间到达时，第一终端需要处于唤醒状态，需要在广播信道上接收网管服务器分发的固件升级包，并根据接收到的固件升级包进行固件升级。

可选地，当第一终端确定自身不属于待升级终端时，则对OTA升级命令不做处理。

本实施例提供的终端OTA升级方法，终端配合网管服务器，可以实现终端的批量升级，缩短了终端OTA升级时间，提高升级效率。

在上述实施例和下述实施例中，当第一终端的版本升级或第一终端的固件存在缺陷需要修复时，网管服务器可以根据升级需求，获取待升级终端的标识地址和地址掩码，并确定升级启动时间。

在一可选实施方式中，上述升级需求包括待升级终端的标识地址和地址掩码。基于此，网管服务器可以直接从升级需求中获取待升级终端的标识地址和地址掩码。

在一可选实施方式中，上述升级需求包括待升级终端的描述信息，例如待升级终端所属终端组、待升级终端负责的业务类型等，这些描述信息可唯一确定待升级终端。基于此，网管服务器可以根据该描述信息计算出待升级终端的标识地址和地址掩码。

在一应用场景中，步骤202中根据待升级地址和地址掩码确定属于待升级终端的一种实施方式可以为：将第一终端的设备地址与OTA升级命令中的地址掩码进行与操作；与操作结果与待升级终端的标识地址相同，则确定第一终端属于待升级终端。

可选地，若上述与操作结果与待升级终端的标识地址不同，则确定第一终端不属于待升级终端。此时，第一终端对于网管服务器下发的OTA升级命令不做处理。

为了更清楚的说明步骤202的实施过程，下面结合具体地址信息和地址掩码进行举例说明。假设终端的设备地址为4字节：

假设OTA升级命令中的标识地址为0x12345678，地址掩码为0xffffffff时，则只有设备地址0x12345678与地址掩码0xffffffff进行与操作的结果和标识地址0x12345678相同，这意味着仅对设备地址为0x12345678的终端进行升级。此时，若第一终端的设备地址为0x12345678，则将该设备地址与地址掩码0xffffffff进行与操作，且与操作的结果与标识地址0x12345678相同，意味着第一终端属于待升级终端；反之，若第一终端的设备地址不是0x12345678，则将该设备地址与地址掩码0xffffffff进行与操作，与操作的结果与标识地址0x12345678不相同，意味着第一终端不属于待升级终端。

当OTA升级命令中待升级终端的标识地址为0x12345600，地址掩码为0xffffff00时，则设备地址0x12345600～0x123456ff与地址掩码0xffffff00进行与操作的结果均和待升级终端的标识地址0x12345600相同，这意味着设备地址为0x12345600～0x123456ff的终端均属于待升级终端。此时，若第一终端的设备地址属于地址范围0x12345600～0x123456ff，则将该设备地址与地址掩码0xffffff00进行与操作，该与操作的结果与标识地址0x12345600相同，表示第一终端属于待升级终端；反之，若第一终端的设备地址不属于地址范围0x12345600～0x123456ff，将该设备地址与地址掩码0xffffff00进行与操作，该与操作的结果与0x1234600不相同，表示第一终端不属于待升级终端。

当OTA升级命令中待升级终端的标识地址为0x00000000，地址掩码为0x00000000时，则任意设备地址与地址掩码0x00000000进行与操作的结果均和待升级终端的标识地址0x00000000相同，意味着所有终端均属于待升级终端。

对于步骤203，在升级启动时间到达时，第一终端在广播信道上接收网管服务器分发的固件升级包。此时，第一终端处于OTA升级模式，会一直保持唤醒状态，并始终保持侦听模式以在广播信道侦听网管服务器分发的固件升级包，以免错失固件升级包。

在一应用场景中，当第一终端加入网络后，一般会处于低功耗休眠状态，但第一终端会定期唤醒，并向网管服务器发送心跳保活报文，以便于网管服务器了解第一终端的存活状态。其中，两个相邻的心跳保活报文之间的时间间隔为一个心跳周期。另外，第一终端也会被一些事件唤醒，从而向网管服务器上报有关数据。每一次上行数据发送都伴随一次下行数据接收窗口，第一终端会在下行数据接收窗口打开期间接收网管服务器下发的数据。其中，终端处于休眠状态时无法接收网管服务器下发的下行数据。对第一终端来说，当处于休眠状态时无法接收网管服务器下发的OTA升级命令或固件升级包。基于此，为了让所有待升级终端都能够有机会接收到网管服务器通过广播信道下发固件升级包，则需要所有待升级终端在网管服务器下发固件升级包的时候(即升级启动时间到达时)都处于唤醒状态。基于上述，OTA升级命令中的升级启动时间可以晚于OTA升级命令下发时刻至少1个心跳周期，其中，至少1个心跳周期可以为大于1个心跳周期的整数个周期，例如2个心跳周期、3个心跳周期等；也可以为大于1个心跳周期的非整数个周期，例如1个半心跳周期等。

进一步，在上述实施例或下述实施例中，在OTA升级命令下发之前，可以对第一终端的时钟进行校准，以使第一终端的时间与网管服务器的时间保持同步。升级启动时间预设在OTA升级命令中，并由网管服务器下发给第一终端。网管服务器根据自身的时钟确定是否到达预设的升级启动时间，当预设的升级启动时间到达时，网管服务器通过广播信道分发固件升级包；第一终端根据自身的时钟确定是否到达预设的升级启动时间，当预设的升级启动时间到达时，第一终端在广播信道上接收固件升级包。在该实施方式中，预先对第一终端与网管服务器的时钟进行校准，有利于保持第一终端上升级启动时间的到达时刻与网管服务器上升级启动时间的到达时刻之间的同步，有利于提高第一终端成功接收到固件升级包的概率。

图3a为本申请一实施例提供的另一种终端OTA升级方法的流程示意图，应用于第一终端。如图3a所示，该方法包括：

301、接收网管服务器下发的OTA升级命令，该OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间。

302、根据待升级终端的标识地址和地址掩码，确定第一终端属于待升级终端。

303、在升级启动时间到达时，在广播信道上接收网管服务器分发的固件升级包。

304、从固件升级包的包头中，解析出固件升级包的描述信息。

305、根据固件升级包的描述信息，对固件升级包进行校验。

306、当固件升级包通过校验后，根据固件升级包进行固件升级。

本实施例中，对步骤301-303的描述可参见上述实施例，此处不再赘述。

本实施例中，为了避免第一终端错误升级或升级失败，当第一终端在广播信道上接收到固件升级包后，从固件升级包的包头中解析出描述信息，根据固件升级包的描述信息，对固件升级包进行校验，当通过校验后，再根据固件升级包进行固件升级，有利于降低无效升级的概率，节约升级资源。

其中，根据升级固件包的格式不同，升级固件包的描述信息也会有所不同。为了更清楚地描述步骤304-306，结合一种示例性固件升级包格式进行描述。在一示例性实施例中，固件升级包格式如图3b所示，包括：包头、固件包内容以及填充部分；其中包头包含：产品ID、版本号、固件包标识长度以及校验和。在该示例中，步骤304中的描述信息包含但不局限于：固件升级包所属的产品ID、版本号、固件包长度以及校验和。

其中，固件包标识长度，用于标识固件升级包的内容长度；固件升级包的内容为第一终端进行升级所需的内容，通常是二进制可执行程序的内容。

相应地，基于上述描述信息，步骤305对固件升级包进行校验至少包括以下至少一种校验操作：

对产品ID进行校验，用于验证固件升级包所属的产品ID与第一终端的产品ID是否一致；

对版本号进行校验，用于验证固件升级包的版本号是否高于第一终端当前的版本号；

对固件包长度进行校验，用于验证接收到的固件升级包的内容长度与固件包包头中的固件包长度是否相等；

对校验和进行校验，用于验证接收到的固件升级包的内容以及填充部分是否被污染或篡改。

可选地，若上述描述信息包括校验和，则当上述步骤305中对校验和进行校验的校验结果为否，且对产品ID、版本号以及固件包长度进行校验的验证结果均为是时，确定第一终端接收到的固件升级包通过校验。可选地，若上述描述信息不包括校验和，则当上述步骤305中对产品ID、版本号以及固件包长度进行校验的验证结果均为是时，确定第一终端接收到的固件升级包通过校验。当固件升级包通过上述校验后再根据固件升级包进行固件升级，可有效避免第一终端进行错误升级或升级失败，进一步提高升级效率。

图4为本申请一实施例提供的又一种终端OTA升级方法的流程示意图，应用于第一终端。如图4所示，该方法包括：

401、接收网管服务器下发的OTA升级命令，该OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间。

402、根据待升级终端的标识地址和地址掩码，确定第一终端属于待升级终端。

403、在升级启动时间到达时，在广播信道上接收网管服务器分发的固件升级包的每个分片。

404、在接收到固件升级包的所有分片后，根据接收到的所有分片进行固件升级。

步骤401和步骤402中接收OTA升级命令和确定第一终端属于待升级终端的描述可参见上述实施例，此处不再赘述。

本实施例中，为了适应网络所支持的报文长度，网管服务器可以将固件升级包切换为多个分片，并在升级启动时间到达时，通过广播信道将固件升级包的每个分片分发给待升级终端。每个分片的长度一般小于网络所支持的最大报文长度。例如，以LPWAN网络为例，LPWAN网络能够传输的报文长度不超过1KB，当传输的报文的大小超过LPWAN网络能够传输的报文大小时，则会出现网络传输链路拥塞、报文丢包、甚至网络崩溃等后果。而一个固件升级包的大小多为MB量级，一般大小为几MB甚至几十MB，因此网管服务器需要将整个固件升级包进行分片，保证每个分片的大小均小于1KB。然后，网管服务器以分片为粒度进行数据传输，通过广播信道将各分片分发给第一终端。可选地，网管服务器可以按照分片在固件升级包中的先后顺序依次广播每个分片，也可以按照随机顺序依次广播每个分片。在本实施例中，每个分片都具有唯一标识，分片的标识不仅可以标识该分片，还可以标识该分片在固件升级包中的先后顺序。其中，分片的标识可以简记为分片ID。

基于上述，在步骤403中，对第一终端来说，当在升级启动时间到达时，在广播信道上接收网管服务器分发的固件升级包的每个分片。此时，第一终端处于OTA升级模式，持续运行，在广播信道始终保持侦听模式，会接收网管服务器广播的每个分片，以免错失固件升级包分片。

当接收到固件升级包的全部分片后，第一终端可以根据接收到的每个分片的标识将接收到的分片重新拼接为固件升级包，再运行固件升级包进行固件升级。这样，可防止固件升级包在传输的过程中出现网络传输链路拥塞、报文丢包、网络崩溃等现象，提高固件升级包传输效率，进而提高终端OTA固件升级效率。

图5a为本申请一实施例提供的又一种终端OTA升级方法的流程示意图，应用于第一终端。如图5a所示，该方法包括：

501、接收网管服务器下发的OTA升级命令，该OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间。

502、根据待升级终端的标识地址和地址掩码，确定第一终端属于待升级终端。

503、在升级启动时间到达时，在广播信道上接收网管服务器分发的固件升级包的每个分片。

504、当在广播信道上接收到网管服务器下发的固件升级包的每个分片时，根据接收到的分片的标识，将位图文件中与接收到的分片对应的比特位设置为第一值，该第一值代表已接收状态。

505、当接收到固件升级包的最后一个分片时，或者在指定时间内未收到固件升级包的任何分片时，确定与位图文件中取值不是第一值的比特位对应的分片作为缺失分片。

506、向网管服务器发送缺失分片请求报文，该缺失分片请求报文携带有缺失分片的标识。

507、在广播信道上接收网管服务器下发的缺失分片。

在本实施例中，步骤501-503的描述可参见上述实施例，此处不再赘述。

在步骤504中，第一终端会根据接收到的分片的标识，在位图文件对应的比特位中标记该分片是否被接收到。对于接收到的分片，可将位图文件中对应的比特位设置为第一值，对于没有接收到的分片，可将位图文件中对应的比特位设置为第一值之外的其它值，例如第二值。可选地，第一值可以为比特“1”；第二值可以为比特“0”，但不限于此。

基于上述位图文件，步骤505中，当分片接收过程结束时，例如当第一终端收到固件升级包最后一个分片时，意味着分片接收过程结束，或者在连续指定时间内未收到固件升级包的任何分片时，也意味着分片接收过程结束，则可通过该位图文件检查接收到的固件升级包分片是否完整；若不完整，则第一终端通过随机信道发送缺失分片请求。具体的，可以分析位图文件中各比特位的取值，从中确定取值不是第一值的比特位，例如可以获取取值为0的比特位，进而确定与位图文件中取值不是第一值的比特位对应的分片作为缺失分片，然后生成缺失分片请求，将缺失分片的标识携带在该缺失分片请求中发送给网管服务器。

网管服务器接收到缺失分片请求后，根据缺失分片请求中所描述的缺失分片，通过广播信道，重新分发缺失分片。由于网管服务器采用广播方式分发缺失分片，因此对于所有缺失该分片的终端均可以收到缺失分片。对第一终端来说，在接收到缺失分片之后会再次更新位图文件。

需要说明的是，第一终端可以将自身设备地址作为随机种子来确定随机信道，然后通过随机信道向网管服务器发送缺失分片请求。因为每个终端的设备地址是不同的，这样以终端的设备地址作为随机种子，各终端选择的随机信道会不相同，可避免海量终端同时发送缺失分片请求导致信道冲突的问题。

可选地，本实施例提供一种固件升级包分片的格式，如图5b所示，包括但不局限于：报头、分片内容以及循环冗余校验(Cyclic Redundancy Check，CRC)部分；其中报头包括但不局限于：报文标识、待升级终端标识地址、地址掩码、分片ID。其中，

报文标识，用于标识报文类型，例如固件升级包分片报文。

待升级终端的标识地址和地址掩码，与OTA升级命令中的待升级标识地址和地址掩码相同，相互配合用于标识可以接收该固件升级包分片的终端。

分片ID，用于标识分片以及分片在固件升级包中的先后顺序，可供终端识别接收到的是哪个分片，以便将分片内容保存到对应的存储区。

分片内容，为固件升级包分片的数据部分，存储的内容为将图3b所示的终端OTA固件升级包的某个分片，其中第一个分片含有固件升级包报头。

基于上述分片ID和分片内容，假设图3b所示的固件升级包的各分片的大小为256字节，分片ID为10(第一个分片的ID表示为0)，则此时固件升级包分片中的分片内容为固件升级包的第2561～2816字节，第一终端将该分片内容保存在程序区偏移起始地址2560个字节的位置，长度为256字节。

对图3b中的填充部分的设置，是为了便于对固件升级包进行分片。由于固件升级包的大小是固定的，且各固件升级包分片报文中的分片内容的大小是相同的，在对固件升级包进行分片时，有可能出现不能平均分片的情况，此时在填充部分中填充比特“0”，使得固件升级包能够按照相同的大小进行平均分片。例如，假设分片内容的大小为256字节，固件包包头的大小为56字节，固件包内容的大小为50000字节，为了保证固件升级包分片的个数为正整数，则需要在填充部分中填充120个比特值“0”，即(56+50000+120)％256＝0，其中“％”为求余运算，当其余数为0时，表示可以整除。此时，固件升级包分片的个数为196，且第一个分片中包含有图3b所示的固件升级包的包头。

CRC部分，为固件升级包分片的CRC校验值，以供终端验证该分片报文在传输过程中是否被污染或篡改。

在一可选实施例中，在根据接收到的分片的标识，将位图文件中与接收到的分片对应的比特位设置为第一值之前，第一终端根据固件升级包的大小创建位图文件(bitmap)，用于记录哪些分片被接收到，哪些分片没有被接收到。例如，固件升级包含有60个分片，则创建的位图文件包括8行，且每行包括8个比特，每个比特按照行序依次代表固件升级包的一个分片。

基于上述假设固件升级包含有60个分片，则创建的位图文件结构示意图如图5c所示。在创建位图文件时，可将各比特位初始化为“0”，当第一终端接收到对应的分片时，则将位图文件中与接收到的分片对应的比特位设置为第一值，图5c所示的第一值为比特值“1”；若第一终端没有接收到对应的分片，则位图文件中对应比特位仍为初始值“0”。如图5c中所示，第一终端没有接收到分片ID为6和12的分片。

需要说明的是，假设的固件包升级分片为60个，则如图5c所示的位图文件中的最后4个比特位是超出固件升级包分片个数的比特位，将其设置为第一值，图5c中为比特值“1”，以便认为这些比特位对应的分片已成功接收到。

这样，结合图5c所示，在步骤505中，当第一终端接收到固件升级包的最后一个分片，或者在指定时间内未接收到固件升级包的分片时，则可确定取值为“0”的比特位对应的分片，即分片ID为6和12的分片为第一终端的缺失分片。

在一可选实施例中，缺失分片请求的报文格式如图5d所示，包括：报头、缺失分片信息以及CRC校验部分；其中，报头包括但不局限于：报文标识、发送终端的标识地址以及报文长度。其中，报文标识，用于标识报文类型，例如是一个缺失分片请求报文；缺失分片信息，可以包含一个或多个缺失分片的分片ID。

当网管服务器接收到该缺失分片请求时，可以根据其中的缺失分片信息确定终端请求的缺失分片，进而通过广播信道下发缺失分片，以便所有缺失对应分片的终端都能够接收到对应的固件升级包分片，提高升级效率。

在本申请实施例中，当终端未能完全下载所有固件升级包分片时，主动请求缺失分片，无需终端对每一个分片都向网管服务器进行确认，减少终端频繁进行射频发送的次数，节省能耗。网管服务器接收到该缺失分片请求时，根据其中的缺失分片信息通过广播信道下发缺失分片，所有缺失该分片的终端都能够接收到该缺失分片，可成倍的缩短批量升级所需的时间，提高升级效率。

图6a为本申请另一实施例提供的一种终端OTA升级方法的流程示意图，应用于第一终端。如图6a所示，包括：

601、接收网管服务器下发的OTA升级命令，该OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间。

602、根据待升级终端的标识地址和地址掩码，确定第一终端属于待升级终端。

603、在升级启动时间到达之前，重启第一终端以运行第一终端的引导程序区中的引导程序，该引导程序包含用于下载固件升级包的精简协议栈。

604、在升级启动时间到达时，运行精简协议栈，以在广播信道上接收网管服务器分发的固件升级包。

605、将第一终端的主程序区中的主程序替换为固件升级包，以完成固件升级。

本申请实施例中，步骤601-602的描述可参见上述实施例，此处不再赘述。

在上述实施例或者下述实施例中，考虑到终端结构较为简单，例如多采用单片机系统，其片上的存储空间(一般为Flash)有限。为了节约终端的存储空间，本申请实施例采用如图6b所示的终端Flash存储空间，包括：引导程序区61、参数区62以及主程序区63；引导程序区61存储有下载固件升级包所需的精简协议栈。

引导程序区61，用于存放引导程序，其中引导程序中包含有引导主程序启动的引导程序和下载固件升级包的精简协议栈。

参数区62，用于非易失存储终端所需的配置，包含有终端是否进行OTA升级的标识。

主程序区63，用于存储主程序，实现终端处理业务所有的功能，包括但不局限于：数据采集、数据处理、分析决策、数据发送与接收等。

在本实施例中，步骤603，在升级启动时间到达之前，重启第一终端可以运行第一终端的引导程序区61中的引导程序，此时，第一终端按照主程序区63的当前固件包处理业务。由于引导程序区61中包含有下载固件升级包所需的精简协议栈，如步骤604所述，在升级启动时间到达时，第一终端运行精简协议栈，在广播信道上接收网管服务器分发的固件升级包，并用该固件升级包替换引导程序区61中的主程序，然后，在第一终端正常启动之后可按照主程序区63的当前固件包处理业务。由此可见，采用本实施例提供的存储结构以及精简协议栈，无需先将固件升级包下载到一备份程序区内，待第一终端重新启动时再由引导程序将主程序区中的主程序替换为备份程序区内的固件升级包。

基于第一终端的引导程序区61中的精简协议栈，第一终端在广播信道上接收到网管服务器分发的固件升级包后，可直接将第一终端的主程序区63中的主程序替换为固件升级包，完成第一终端固件升级，无需占用额外存储空间，有利于节约第一终端的存储空间。

图7为本申请又一实施例提供的一种终端OTA升级方法的流程示意图，应用于网管服务器。如图7所示，该方法包括：

701、根据升级需求，获取待升级终端的标识地址和地址掩码。

702、向待升级终端下发OTA升级命令，该OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间。

703、在升级启动时间到达时，通过广播信道向待升级终端分发固件升级包，以供待升级终端接收该固件升级包并进行升级。

在上述实施例和下述实施例中，当终端的版本升级或终端的固件存在缺陷需要修复时，网管服务器可以根据升级需求，获取待升级终端的标识地址和地址掩码，并确定升级启动时间。

在一可选实施方式中，上述升级需求包括待升级终端的标识地址和地址掩码。基于此，网管服务器可以直接从升级需求中获取待升级终端的标识地址和地址掩码。

在一可选实施方式中，上述升级需求包括待升级终端的描述信息，例如待升级终端所属终端组、待升级终端负责的业务类型等，这些描述信息可唯一确定待升级终端。基于此，网管服务器可以根据该描述信息计算出待升级终端的标识地址和地址掩码。

在一可选实施方式中，为了适应网络所支持的报文长度，网管服务器可以将固件升级包切换为多个分片，并在升级启动时间到达时，通过广播信道将固件升级包的各分片分发给待升级终端。各分片的长度一般小于网络所支持的最大报文长度。例如，以LPWAN网络为例，LPWAN网络能够传输的报文长度不超过1KB，当传输的报文的大小超过LPWAN网络能够传输的报文大小时，则会出现网络传输链路拥塞、报文丢包、甚至网络崩溃等后果。而一个固件升级包的大小多为MB量级，一般大小为几MB甚至几十MB，因此网管服务器需要将整个固件升级包进行分片，保证每个分片的大小均小于1KB。然后，网管服务器以分片为粒度进行数据传输，通过广播信道将各分片分发给第一终端。

基于此，步骤703的一种实施方式可以为：在升级启动时间到达时，通过广播信道向待升级终端分发固件升级包的每个分片，以供待升级终端接收固件升级包的每个分片。当待升级终端接收到固件升级包的全部分片后，根据接收到的每个分片的标识将接收到的分片重新拼接为固件升级包，再运行固件升级包进行固件升级。这样，可防止固件升级包在传输的过程中出现网络传输链路拥塞、报文丢包、网络崩溃等现象，提高固件升级包传输效率，进而提高终端OTA固件升级效率。

本实施例中，网管服务器通过一标识地址和地址掩码来标识需要进行固件升级的待升级终端；通过下发OTA升级命令并在OTA升级命令中携带统一的升级启动时间，使得待升级终端可以在升级启动时间到达时，统一唤醒并在广播信道上接收网管服务器分发的升级固件包进行固件升级，可以实现待升级终端的批量升级，提高网络终端升级效率。

图8为本申请又一实施例提供的另一种终端OTA升级方法的流程示意图，应用于网管服务器。如图8所示，该方法包括：

801、根据升级需求，获取待升级终端的标识地址和地址掩码。

802、向待升级终端下发OTA升级命令，该OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间。

803、在升级启动时间到达时，通过广播信道向待升级终端分发固件升级包分片，以供待升级终端接收该固件升级包分片。

804、接收待升级终端中第一终端发送的缺失分片请求，该缺失分片请求携带有缺失分片的标识；

805、通过广播信道向所述第一终端发送缺失分片。

本申请实施例中，步骤801-803的描述可参见上述实施例，此处不再赘述。

在分发固件升级包的分片的过程中可能出现丢包现象。若第一终端未能完全接收到固件升级包的所有分片，则会向网管服务器发送携带有缺失分片标识的缺失分片请求，网管服务器接收到该缺失分片请求后，通过广播信道向第一终端发送相应的缺失分片。这样，不仅第一终端可接收该缺失分片，未发送缺失分片请求但缺失该分片的其他终端也可接收该缺失分片，可避免同一缺失分片请求的重复发送，进一步提高网络终端升级效率。

在下面实施例中，将结合图1b所示物联网系统对本申请实施例提供的对终端进行批量升级的方法流程进行描述。终端OTA升级过程可分为：升级准备阶段和升级执行阶段。

图9为本申请又一实施例提供的终端OTA升级准备阶段交互流程示意图。如图9所示，该交互流程包括：

终端启动后，向物联网基站发送请求加入网络报文，该请求加入网络报文中包含有终端的终端类型、版本号以及设备地址等信息。

物联网基站接收终端发送的请求加入网络报文，并对该报文进行验证。验证通过后，允许终端加入网络，并向终端回应加入网络成功报文。物联网基站还将终端上线的消息通告给物联网平台，物联网平台进一步通告给网管服务器，该消息中包含有成功加入网络的各终端相应的终端类型、版本号以及设备地址等信息。

在确定终端加入网络后，网管人员可以通过网管服务器按需控制待升级终端进行OTA升级，网管服务器向待升级终端下发OTA升级命令。

考虑到终端加入网络后，通常会进入低功耗休眠状态，在休眠状态下终端无法接收网管服务器下发的数据，例如无法接收OTA升级命令。因此，在本系统中，终端进入低功耗休眠状态后，会定期唤醒并向网管服务器发送心跳保活报文，该心跳保活报文通过物联网基站和物联网平台转发给网管服务器，网管服务器可通过该心跳保活报文判断终端是否存活。当网管服务器在连续一段时间内一直没有接收到心跳保活报文，则认为终端已经离线。其中，终端每次唤醒后可进行一次上行数据发送，并伴随一次下行接收窗口。在该窗口期间，终端处于侦听状态，可以接收物联网基站下发的下行报文。

基于上述，在终端进入低功耗状态无法接收网管服务器下发的OTA升级命令的情况下，物联网平台可缓存该OTA升级命令，并在终端的下一个上行数据或心跳保活报文到来时，在伴随的下行接收窗口期间将缓存的OTA升级指令下发给终端，终端在下行接收窗口打开期间接收该OTA升级命令，该OTA升级命令中携带有待升级终端的标识地址、地址掩码以及升级启动时间等信息。

当终端接收到该OTA升级命令时，根据OTA升级命令中的待升级终端的标识地址和地址掩码，确定自身是否属于待升级终端。至此，终端OTA升级准备阶段完成。对于确定为属于待升级终端的终端将进入OTA升级执行阶段。

图10为本申请又一实施例提供的终端OTA升级执行阶段交互流程示意图。如图10所示，该交互流程包括：

待升级终端经过上述升级准备阶段，进行复位重启后，运行引导程序。

在引导程序中检查参数区，判断是否含有OTA升级标识。若判断结果为是，进入OTA升级模式，初始化升级分片接收记录的位图文件；在OTA升级模式下，终端持续运行，在广播信道保持侦听模式，以免错失物联网基站下发的固件升级包的分片。若判断结果为否，则不做后续处理。

待升级终端到达升级启动时间后，网管服务器开始通过广播信道分发固件升级包的分片报文，所有终端在广播信道接收固件升级包的分片报文。

终端在收到固件升级包的分片报文后，根据报文中的CRC字段校验报文内容是否正确。若CRC校验正确，则继续检查报文标识是否为升级包分片报文、本终端地址是否与报文中标识地址和掩码匹配、分片ID是否在允许的范围内，如果均通过校验，则在位图文件将当前分片标识为已收到；如果CRC校验失败则不进行后续处理。

当网管服务器发送完所有分片，则开始等待接收来自终端的缺失分片请求。

当终端收到最后一个分片或者在连续指定时间内未收到固件升级包分片时，开始检查终端收到的分片是否完整。若终端接收到的分片不完整，则终端通过随机数据信道发送缺失分片请求；若终端接收到的分片完整，则对固件升级包进行校验。

网管服务器收到终端发送的缺失分片请求后，根据该请求所描述的缺失分片，通过广播信道重新分发缺失分片；终端在广播信道上接收该缺失分片，并再次更新第一终端记录分片报文的位图文件。

上述步骤终端发送缺失分片请求、网管服务器分发对应的缺失分片以及终端校验接收到的分片是否完整反复循环，使所有待升级终端都接收到完整的固件升级包。

终端在接收到整个固件升级包后，对固件升级包进行校验，包括产品ID、版本号、固件包长度、校验和。若校验成功，则将OTA升级完成标识写入参数区；若检验失败，则不做后续处理。

终端进行复位，检测到参数区OTA升级已经完成，则跳转到程序区执行最新的固件版本，完成本次OTA升级。

图11为本申请又一实施例提供的一种终端的结构示意图。如图11所示，该终端110包括：第一接收模块1101、确定模块1102、第二接收模块1103以及升级模块1104。

第一接收模块1101，用于接收网管服务器下发的OTA升级命令，该OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间。

确定模块1102，用于根据待升级终端的标识地址和地址掩码，确定终端属于待升级终端。

第二接收模块1103，用于在升级启动时间到达时，在广播信道上接收网管服务器分发的固件升级包。其中，升级启动时间晚于OTA升级命令下发时刻至少1个心跳周期。至少1个心跳周期可以为大于1个心跳周期的整数个周期，例如2个心跳周期、3个心跳周期等；也可以为大于1个心跳周期的非整数个周期，例如1个半心跳周期等。

升级模块1104，用于根据固件升级包进行固件升级。

在一可选实施例中，确定模块1102在确定终端属于待升级终端时，具体用于：

将终端的设备地址与地址掩码进行与操作；

若与操作的结果与待升级终端的标识地址相同，确定该终端属于待升级终端。

在一可选实施例中，第二接收模块1103在接收网管服务器分发的固件升级包时，具体用于：在升级启动时间到达时，在广播信道上接收网管服务器下发的固件升级包的每个分片。

进一步，当第二接收模块1103接收到网管服务器下发的固件升级包的每个分片时，第二接收模块1103还用于：根据接收到的分片的标识，将位图文件中与所述接收到的分片对应的比特位设置为第一值，其中第一值代表已接收状态。

进一步，当第二接收模块1103接收到固件升级包的最后一个分片时，或者在指定时间内未收到固件升级包的任何分片时，第二接收模块1103还用于：确定与上述位图文件中取值不是第一值的比特位对应的分片作为缺失分片。

相应地，在一可选实施方式中，基于上述缺失分片，终端110还包括发送模块，用于向网管服务器发送缺失分片请求，且该缺失分片请求携带有相应的缺失分片的标识。

相应地，当网管服务器根据上述缺失分片请求通过广播信道分发相应的缺失分片时，第二接收模块1103用于在广播信道上接收网管服务器下发的缺失分片。

在一可选实施例中，升级模块1104在根据升级包进行固件升级时，具体用于：

从固件升级包的包头中，解析出固件升级包的描述信息；

根据固件升级包的描述信息，对固件升级包进行校验；

当固件升级包通过校验后，根据固件升级包进行升级。

在一可选实施例中，终端110还包括重启模块，用于：在确定终端110属于待升级终端之后，而在升级启动时间到达之前，重启该终端以运行终端110的引导程序区中的引导程序，该引导程序包含用于下载固件升级包的精简协议栈。

相应地，基于上述精简协议栈，第二接收模块1103在广播信道上接收网管服务器分发的固件升级包时，具体用于：在升级启动时间到达时，运行精简协议栈，以在广播信道上接收网管服务器分发的固件升级包。

相应地，升级模块1104在根据固件升级包进行固件升级时，具体用于：将终端设备的主程序区中的主程序替换为该固件升级包，以完成固件升级。

图12为本申请又一实施例提供的一种网管服务器的结构示意图。如图12所示，该网管服务器120包括：获取模块1201、下发模块1202以及分发模块1203。

获取模块1201，用于根据升级需求，获取待升级终端的标识地址和地址掩码；

下发模块1202，用于向待升级终端广播OTA升级命令，该OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间；

分发模块1203，用于在升级启动时间到达时，通过广播信道向待升级终端分发固件升级包，以供待升级终端接收固件升级包并进行升级。

在一可选实施方式中，分发模块1203在通过向待升级终端分发固件升级包时，具体用于：在升级启动时间到达时，通过广播信道向待升级终端分发固件升级包的每个分片。

在一可选实施方式中，网管服务器120向待升级终端分发的固件升级包的各分片在传输过程中可能出现部分分片丢包，以致待升级终端中的第一终端出现分片缺失，向网管服务器120发送相应的缺失分片请求。基于此，网管服务器120还可包括接收模块，用于接收待升级终端中第一终端发送的缺失分片请求，缺失分片请求携带有所述缺失分片的标识。

相应地，在网管服务器120接收到上述缺失分片请求时，分发模块1203用于通过广播信道向第一终端发送相应的缺失分片。

本实施例提供的网管服务器与前述实施例提供的终端相互配合使用，实现终端OTA固件升级。即网管服务器通过一标识地址和地址掩码来标识需要进行固件升级的待升级终端；通过下发OTA升级命令并在OTA升级命令中携带统一的升级启动时间，使得待升级终端可以在升级启动时间到达时，统一唤醒并在广播信道上接收网管服务器分发的升级固件包进行固件升级。本申请实施例提供的终端和网管服务器相互配合，可以对待升级终端进行批量升级，可缩短终端OTA升级时间，提高升级效率。

需要说明的是，本申请实施例提供的技术方案，不仅适用于LPWAN网络，同样适用于非LPWAN网络，比如蓝牙等。另外，本申请实施例提供的技术方案涉及批量下发固件升级包，但不限于此，也可用于其他需要批量下发提高效率的场景。

还需要说明的是，在上述实施例及附图中的描述的一些流程中，包含了按照特定顺序出现的多个操作，但是应该清楚了解，这些操作可以不按照其在本文中出现的顺序来执行或并行执行，操作的序号如101、102等，仅仅是用于区分开各个不同的操作，序号本身不代表任何的执行顺序。另外，这些流程可以包括更多或更少的操作，并且这些操作可以按顺序执行或并行执行。需要说明的是，本文中的“第一”、“第二”等描述，是用于区分不同的消息、设备、模块等，不代表先后顺序，也不限定“第一”和“第二”是不同的类型。

本领域内的技术人员应明白，本发明的实施例可提供为方法、系统、或计算机程序产品。因此，本发明可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本发明可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本发明是参照根据本发明实施例的方法、设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、商品或者设备中还存在另外的相同要素。

以上所述仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (14)

1.一种终端OTA升级方法，应用于第一终端，其特征在于，所述方法包括：

接收网管服务器下发的OTA升级命令，所述OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间；

根据所述待升级终端的标识地址和所述地址掩码，确定所述第一终端属于所述待升级终端；

在所述升级启动时间到达时，在所述广播信道上接收所述网管服务器分发的固件升级包；

根据所述固件升级包进行固件升级。

2.根据权利要求1所述方法，其特征在于，所述根据所述待升级终端的标识地址和所述地址掩码，确定所述第一终端属于所述待升级终端，包括：

将所述第一终端的设备地址与所述地址掩码进行与操作；

若与操作的结果与所述待升级终端的标识地址相同，确定所述第一终端属于所述待升级终端。

3.根据权利要求1所述方法，其特征在于，所述升级启动时间晚于所述OTA升级命令下发时刻至少1个心跳周期。

4.根据权利要求1所述方法，其特征在于，所述在所述升级启动时间到达时，在所述广播信道上接收所述网管服务器分发的固件升级包，包括：

在所述启动时间到达时，在所述广播信道上接收所述网管服务器下发的所述固件升级包的每个分片。

5.根据权利要求4所述方法，其特征在于，还包括：

当在所述广播信道上接收到所述网管服务器下发的所述固件升级包的每个分片时，根据所述接收到的分片的标识，将位图文件中与所述接收到的分片对应的比特位设置为第一值，所述第一值代表已接收状态。

6.根据权利要求5所述方法，其特征在于，还包括：

当接收到所述固件升级包的最后一个分片时，或者在连续指定时间内未收到所述固件升级包的任何分片时，根据所述位图文件中各比特位的取值，确定取值不是所述第一值的比特位对应的分片作为缺失分片；

向所述网管服务器发送缺失分片请求，所述缺失分片请求携带有所述缺失分片的标识；以及

在所述广播信道上接收所述网管服务器下发的所述缺失分片。

7.根据权利要求1所述方法，其特征在于，所述根据所述固件升级包进行固件升级，包括：

从所述固件升级包的包头中，解析出所述固件升级包的描述信息；

根据所述固件升级包的描述信息，对所述固件升级包进行校验；

当所述固件升级包通过校验后，根据所述固件升级包进行升级。

8.根据权利要求1-7任一项所述的方法，其特征在于，在确定所述第一终端属于所述待升级终端之前，所述方法还包括：

在所述升级启动时间到达之前，重启所述第一终端以运行所述第一终端的引导程序区中的引导程序，所述引导程序包含用于下载所述固件升级包的精简协议栈；

在所述升级启动时间到达时，在所述广播信道上接收所述网管服务器分发的固件升级包，包括：

在所述升级启动时间到达时，运行所述精简协议栈，以在所述广播信道上接收所述网管服务器分发的固件升级包；

所述根据所述固件升级包进行固件升级，包括：

将所述第一终端设备的主程序区中的主程序替换为所述固件升级包，以完成固件升级。

9.一种终端OTA升级方法，应用于网管服务器，其特征在于，所述方法包括：

根据升级需求，获取待升级终端的标识地址和地址掩码；

向所述待升级终端下发OTA升级命令，所述OTA升级命令包括所述待升级终端的标识地址、地址掩码以及升级启动时间；

在所述升级启动时间到达时，通过所述广播信道向所述待升级终端分发固件升级包，以供所述待升级终端接收所述固件升级包并进行升级。

10.根据权利要求9所述的方法，其特征在于，在所述升级启动时间到达时，通过所述广播信道向所述待升级终端分发固件升级包，包括：

在所述升级启动时间到达时，通过所述广播信道向所述待升级终端分发所述固件升级包的每个分片。

11.根据权利要求10所述的方法，其特征在于，还包括：

接收所述待升级终端中第一终端发送的缺失分片请求，所述缺失分片请求携带有所述缺失分片的标识；

通过所述广播信道向所述第一终端发送所述缺失分片。

12.一种终端，其特征在于，包括：

第一接收模块，用于接收网管服务器下发的OTA升级命令，所述OTA升级命令包含待升级终端的标识地址、地址掩码以及升级启动时间；

确定模块，用于根据所述待升级终端的标识地址和所述地址掩码，确定所述终端属于所述待升级终端；

第二接收模块，用于在所述升级启动时间到达时，在所述广播信道上接收所述网管服务器分发的固件升级包；

升级模块，用于根据所述固件升级包进行固件升级。

13.一种网管服务器，其特征在于，包括：

获取模块，用于根据升级需求，获取待升级终端的标识地址和地址掩码；

下发模块，用于向所述待升级终端下发OTA升级命令，所述OTA升级命令包括所述待升级终端的标识地址、地址掩码以及升级启动时间；

分发模块，用于在所述升级启动时间到达时，通过所述广播信道向所述待升级终端分发固件升级包，以供所述待升级终端接收所述固件升级包并进行升级。

14.一种OTA升级系统，其特征在于，包括：权利要求12所述的终端以及权利要求13所述的网管服务器。