CN108449198A - 一种ota升级的方法、系统及存储设备 - Google Patents

Abstract

本申请公开了一种OTA升级的方法、系统及存储设备，该OTA升级的方法应用于终端设备和协调器，通过在终端设备被唤醒时，终端设备将事件包发送给协调器；协调器根据事件包判断是否有与终端设备对应的升级包；若是，则协调器发送通知包给终端设备，终端设备获取当前固件的类型，并判断当前固件的类型与通知包的类型是否匹配；若判断到当前固件的类型与通知包的类型匹配，则终端设备设置禁止进入休眠状态的标志位，并发送升级请求包给协调器；协调器根据升级请求包向终端设备传输升级包；终端设备根据升级包进行升级，能够实现OTA快速升级，减少了OTA升级所消耗的时间。

Description

一种OTA升级的方法、系统及存储设备

技术领域

本申请应用于OTA升级技术领域，特别是涉及一种OTA升级的方法、系统及存储设备。

背景技术

在Zigbee网络中的三种逻辑设备，协调器与路由器都是长供电的，而终端设备一般是电池供电，大部分情况下是处在休眠模式中。

在传统的OTA升级流程中，在终端设备每次被唤醒时，在发送自己事件包的同时会附带一个OTA的请求包，这样每次唤醒就去请求一次，对于那种一天可能唤醒次数不多的设备，一次OTA升级可能会持续数月都是可能的，导致用户体验不佳，而且对于固件版本更新也是有很大的影响。

发明内容

本申请提供涉及一种OTA升级的方法、系统及存储设备，以解决OTA无法方便快速升级的问题。

为解决上述技术问题，本申请采用的一个技术方案是：提供一种OTA升级的方法，应用于终端设备和协调器，该方法包括在终端设备被唤醒时，终端设备将事件包发送给协调器；协调器根据事件包判断是否有与终端设备对应的升级包；若是，则协调器发送通知包给终端设备，终端设备获取当前固件的类型，并判断当前固件的类型与通知包的类型是否匹配；若判断到当前固件的类型与通知包的类型匹配，则终端设备设置禁止进入休眠状态的标志位，并发送升级请求包给协调器；协调器根据升级请求包向终端设备传输升级包；终端设备根据升级包进行升级。

为解决上述技术问题，本申请采用的另一个技术方案是：提供一种OTA升级的系统，该系统包括终端设备以及协调器；其中，在终端设备被唤醒时，终端设备将事件包发送给协调器；协调器根据事件包判断是否有与终端设备对应的升级包；若是，则协调器发送通知包给终端设备，终端设备获取当前固件的类型，并判断当前固件的类型与通知包的类型是否匹配；若判断到当前固件的类型与通知包的类型匹配，则终端设备设置禁止进入休眠状态的标志位，并发送升级请求包给协调器；协调器根据升级请求包向终端设备传输升级包；终端设备根据升级包进行升级。

为解决上述技术问题，本申请采用的又一个技术方案是：提供一种存储设备，该存储设备用于存储程序数据，程序数据能够被执行以实现上述方法中任一项的方法。

本申请的有益效果是：在终端设备被唤醒时，终端设备将事件包发送给协调器；协调器根据事件包判断是否有与终端设备对应的升级包；若存在，则协调器发送通知包给终端设备，终端设备从通知包中获取当前固件的类型，并判断当前固件的类型与通知包的类型是否匹配；若判断到当前固件的类型与通知包的类型匹配，则终端设备设置禁止进入休眠状态的标志位，并发送升级请求包给协调器，避免了终端设备在OTA升级过程中休眠，保证了OTA升级过程的连续；协调器根据升级请求包向终端设备传输升级包；终端设备接收完成后根据升级包对固件进行升级，能够实现OTA快速升级，减少了OTA升级所消耗的时间。

附图说明

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

图1是本申请一种OTA升级的方法一实施例的流程示意图；

图2是本申请一种OTA升级的方法又一实施例的流程示意图；

图3是本申请OTA升级的系统一实施例的结构示意图。

具体实施例

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述。可以理解的是，此处所描述的具体实施例仅用于解释本申请，而非对本申请的限定。另外还需要说明的是，为了便于描述，附图中仅示出了与本申请相关的部分而非全部结构。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例所提供的终端设备，包括智能移动终端、平板电脑、智能穿戴设备、数字音视频播放器、电子阅读器、手持游戏机等终端设备。

本申请中的术语“包括”和“具有”以及它们任何变形，意图在于覆盖不排他的包含。例如包含了一系列步骤或单元的过程、方法、系统、产品或设备没有限定于已列出的步骤或单元，而是可选地还包括没有列出的步骤或单元，或可选地还包括对于这些过程、方法、产品或设备固有的其它步骤或单元。

在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本申请的至少一个实施例中。在说明书中的各个位置出现该短语并不一定均是指相同的实施例，也不是与其它实施例互斥的独立的或备选的实施例。本领域技术人员显式地和隐式地理解的是，本文所描述的实施例可以与其它实施例相结合。

请参阅图1，图1是本申请一种OTA升级的方法一实施例的流程示意图。本实施例所揭示的方法应用于终端设备和协调器，具体来说可以包括以下步骤：

S11：在终端设备被唤醒时，终端设备将事件包发送给协调器。

在本实施例中，终端设备准备OTA升级时，终端设备被唤醒，终端设备将事件包发送给协调器。

其中，OTA升级，即Over－the－Air，空中下载技术，是指可以不需要连接电脑、不通过数据线连接的方式实现移动终端系统的升级的方式。终端设备以移动终端为例来说明，移动终端OTA升级是指Android系统提供的标准软件升级方式，可以无损失升级系统，主要手段是通过网络(包括WIFI、3G)自动下载OTA升级包、自动升级，也支持通过下载OTA升级包到SD卡升级。

终端设备的事件包可以包含终端设备的相关信息，例如设备型号、应用程序的最近更新日期、系统的版本号等等，事件包所包含的信息可以遵循默认的出厂设置，也可以根据实际需求发送所需的终端设备的相关信息内容。

在本步骤S11中，在准备OTA升级时，终端设备被唤醒，终端设备将包含终端设备相关信息的事件包发送给协调器，以使协调器在下述步骤S12中根据事件包进行相关处理。

S12：协调器根据事件包判断是否有与终端设备对应的升级包。

在上述步骤S11中，终端设备发送事件包给协调器后，在本步骤S12中，协调器会根据接收到的事件包来判断协调器本地是否存在有与终端设备相对应的升级包。

具体来说，当协调器接收到终端设备发送的事件包后，对事件包的内容进行解析，并获取用来判断协调器本地是否存在有与终端设备相对应的升级包的信息，例如，升级包对应的是v031版本的系统，则从事件包中获取终端设备的系统版本，判断终端设备的系统版本是否为v031版本，若判断结果为是，则执行下述步骤S13。

S13：协调器发送通知包给终端设备，终端设备获取当前固件的类型，并判断当前固件的类型与通知包的类型是否匹配。

在上述步骤S12中，当协调器根据事件包判断出有与终端设备对应的升级包时，则协调器发送通知包给终端设备，以通知终端设备存在升级包。终端设备在接收通知包后去获取当前的固件类型，其中，固件(Firmware)是指写入EROM(可擦写只读存储器)或EEPROM(电可擦可编程只读存储器)中的程序，固件是指设备内部保存的设备“驱动程序”，通过固件，操作系统才能按照标准的设备驱动实现特定机器的运行动作，比如光驱、刻录机等都有内部固件，终端设备在获取到当前固件的类型后，判断当前固件的类型与通知包的类型是否匹配，若判断到当前固件的类型与通知包的类型匹配，则执行下述步骤S14。

S14：终端设备设置禁止进入休眠状态的标志位，并发送升级请求包给协调器。

终端设备在OTA升级时，若是以补丁方式的进行小更新，则需要流量的数值在从几兆到十几兆；若是进行大的更新，则相当于对终端设备完全刷机，此时需要流量的数值要一百多兆，因此终端设备在OTA升级时无论何种更新都需要一定的时间。但一般情况下，在OTA的流程中终端设备在上述步骤S11中被唤醒之后在上报事件之后，在上述步骤S13中收到回复的通知包后会进入休眠，终端设备每被唤醒一次才执行一次发送信息给协调器，由于每次的数据传输的数据大小都有限，就会导致终端设备在每次OTA升级时持续时间较长，对于一些唤醒次数不多的终端设备，一次OTA可能会持续数月，对用户体验和固件的版本升级都产生非常大的影响。然而在本实施例中，在判断到当前固件的类型与通知包的类型匹配时，使终端设备设置禁止进入休眠状态的标志位，以避免终端设备在执行本步骤S14后进入休眠状态，终端设备发送升级请求包给协调器，使得OTA升级能持续进行。

S15：协调器根据升级请求包向终端设备传输升级包。

在上述步骤S14中，终端设备发送升级请求包给协调器后，在本步骤S15中，协调器接收到升级请求包，根据升级请求包的信息，将匹配的升级包向终端设备传输，传输升级包时，传输数据的数值可以按阶梯式传输，也可以每次都传输相同的数值，具体传输方式此处不做限定。

S16：终端设备根据升级包进行升级。

在本步骤S16中，终端设备接收到上述步骤S15中协调器传输的升级包，在接收完毕后，终端设备根据升级包进行升级，此时终端设备OAT升级完成。

本实施例在终端设备被唤醒时，终端设备将事件包发送给协调器；协调器根据事件包中的相关信息判断是否有与终端设备对应的升级包；若存在，则协调器发送通知包给终端设备，终端设备从通知包中获取当前固件的类型，并判断当前固件的类型与通知包的类型是否匹配；若判断到当前固件的类型与通知包的类型匹配，则终端设备设置禁止进入休眠状态的标志位，并发送升级请求包给协调器，避免了终端设备在OTA升级过程中休眠，保证了OTA升级过程的连续；协调器根据升级请求包向终端设备传输升级包；终端设备接收完成后根据升级包对固件进行升级，能够实现OTA快速升级，减少了OTA升级所持续的时间，保证终端设备固件版本及时更新的效果。

请参阅图2，图2是本申请一种OTA升级的方法又一实施例的流程示意图。本实施例所揭示的方法应用于终端设备和协调器，具体来说可以包括以下步骤：

S21：在终端设备被唤醒时，终端设备将事件包发送给协调器。

在本实施例中，终端设备和协调器通过Zigbee协议建立通信，其中，Zigbee是基于IEEE802.15.4协议的。在终端设备与协调器基于Zigbee协议建立的网络中，均各自拥有一个唯一的MAC(媒体访问控制子层，负责为一个节点和它的相邻节点之间提供可靠通讯，帮助避免碰撞和提高效率，MAC层还负责打包和分解数据包和帧)地址，协调器在建立网络以后会设置一个短地址，例如，将0x0000设置为协调器的短地址，终端设备加入网络以后，也会得到一个短地址，例如，将0x0014设置为终端设备的短地址。

在本步骤S21中，终端设备准备OTA升级时，终端设备被唤醒，终端设备将事件包发送给协调器，其中，事件包中可以包含终端设备的短地址与设备类型，以使协调器在下述步骤S22中根据事件包进行相关处理。其他实施方式与上述方法中类似，此处不做赘述。

S22：协调器根据事件包判断是否有与终端设备对应的升级包。

在上述步骤S21中，终端设备发送包含终端设备的短地址与设备类型的事件包给协调器后，在本步骤S22中，协调器会根据接收到的事件包来判断协调器本地是否存在有与终端设备相对应的升级包。

具体来说，协调器接收到终端设备发送的事件包后，对事件包的内容进行解析，并获取终端设备的短地址与设备类型，来检测协调器本地是否存在有与终端设备相对应的升级包的信息，若检测到协调器已经预先下载了相应的升级包，则执行下述步骤S23。

S23：协调器发送通知包给终端设备，终端设备获取当前固件的类型，并判断当前固件的类型与通知包的类型是否匹配。

在上述步骤S22中，当协调器根据事件包判断出有与终端设备对应的升级包时，则协调器发送通知包给终端设备，以通知终端设备存在升级包。终端设备在接收通知包后会解析通知包中的信息，例如版本号、设备ID、固件类型等等，并判断解析出来的信息与当前终端设备相关信息是否匹配，若是，则执行下述步骤S24。

例如，终端设备获取当前的固件类型，当前的固件类型为sReceivedFrame.u16ImageType，接收到的通知包的类型为sOTAHeader.u16ImageType，判断当前固件的类型与通知包的类型是否匹配，即判断sReceivedFrame.u16ImageType与sOTAHeader.u16ImageType是否相匹配时，若是，则执行下述步骤S24，若判断结果为否，则终端设备不做任何处理。其他实施方式与上述方法中类似，此处不做赘述。

S24：终端设备设置禁止进入休眠状态的标志位，并发送升级请求包给协调器，协调器判断已经本地下载的升级包的版本号是否与升级请求包的版本号匹配。

在上述步骤S23中终端设备判断到当前固件的类型与通知包的类型匹配时，终端设备会向协调器发送升级请求包，例如，终端设备发送eOTA＿ClientQueryNextImageRequest给协调器以作为升级包的请求包，此时终端设备会设置禁止进入休眠状态的标志位，例如，通过jrd＿set＿otaflag(TRUE)来设置标志位，在终端设备每次准备进入休眠的时候会检测这个标志位，如果为TRUE，则不会调用响应的API接口(Application Programming Interface，应用程序编程接口)进入休眠，从而使得终端设备能不进入休眠状态，继而OTA升级能持续进行。

在本实施例中，升级请求包至少包括版本号，还可以包括制造商ID、设备类型、版本号等信息，在本步骤S24中，协调器判断已经本地下载的升级包的版本号是否与升级请求包的版本号匹配，若匹配成功，则执行下述步骤S25，若匹配不成功，则执行下述步骤S26。其他实施方式与上述方法中类似，此处不做赘述。

S25：协调器向终端设备发送成功状态的回复包。

若在上述步骤S24中判断到升级包的版本号与升级请求包的版本号匹配，则在本步骤S25中协调器向终端设备发送回复包，其中回复包包括OTA＿STATUS＿SUCCESS状态、升级包的大小以及升级包的版本号，OTA＿STATUS＿SUCCESS状态用于显示升级请求成功，其中，状态信息可携带其他信息，例如包含短地址的OTA＿STATUS＿SUCCESS(0x00)。

S26：协调器向终端设备发送失败状态的信息。

若判断到升级包的版本号与升级请求的版本号未匹配成功，则协调器向终端设备发送包括OTA＿STATUS＿NO＿IMAGE＿AVAILABLE状态的回复包，OTA＿STATUS＿NO＿IMAGE＿AVAILABLE状态用于显示升级请求失败，即作为错误代码被协调器发送给终端设备。

S27：终端设备发送块请求给协调器。

在上述步骤S24中，终端设备接收到包括OTA＿STATUS＿SUCCESS状态的回复包后，在本步骤S27中，终端设备发送块请求给协调器，以使协调器根据块请求获取升级包，并向终端设备传输升级包。

具体来说，终端设备在接收到OTA＿STATUS＿SUCCESS状态的回复包后，会调用vOtaRequestNextBlock接口来开始升级包内容的请求，即块请求。Zigbee协议中MAC(媒体访问控制子层)层的包的最大值是127Byte，在去除Zigbee协议中各层(MAC/NWK(网络层)/APS(应用支持子层)/ZCL(Zigbee簇群库))添加的头部信息外，基本上每个块回复包中包含的净数据最大值不会超过80Byte，一般的默认值是48Byte，因此在本实施例中，根据Zigbee协议的限制，每次块请求的数据设定为48byte。此时作为升级包传输的开始，升级包是按照偏移量去请求的，并且每一次请求一定的二进制内容，第一次请求是从0开始，其中，偏移量是指把存储单元的实际地址与其所在段的段地址之间的距离称为段内偏移，也称为“有效地址”。

S28：终端设备进入休眠状态。

在上述步骤S26中，终端设备接收到包括OTA＿STATUS＿NO＿IMAGE＿AVAILABLE状态的回复包后，在本步骤S28中，终端设备通过调用jrd＿set＿otaflag(FALSE(假))来恢复休眠功能，以使终端设备进入休眠状态。

S29：协调器根据升级请求包向终端设备传输升级包。

在上述步骤S27中终端设备发送块请求给协调器后，在本步骤S29中，协调器根据升级请求包向终端设备传输升级包，即在收到块请求时，根据包中的偏移地址已经请求块大小，来向终端设备传输指定大小与位置的升级包内容作为块回复。

终端设备接收到协调器发来的块回复包后，应用层会回复ACK这一确认字符给协调器，如果协调器没有收到这个ACK，则终端设备与协调器会在一定时间之后会重复多次执行块请求与块回复两个步骤，直至应用层回复ACK这一确认字符给协调器，从而实现升级包内容的传输。

S30：终端设备向协调器发送结束请求包。

当上述步骤S29中协调器向终端设备传输升级包后，在本步骤S30中，终端设备会对接收的升级包的大小与回复包中升级包的大小是否匹配进行检测，当检测到接收的升级包大小与回复包中升级包的大小相匹配时，终端设备向协调器发送结束请求包，以使协调器接收到结束请求包时，向终端设备发送结束回复包。

S31：终端设备在CRC检测成功后，根据升级包进行升级。

在本步骤S31中，协调器响应该结束请求包而向终端设备发送结束回复包，使得终端设备接收结束回复包后，对升级包进行CRC(Cyclic Redundancy Check，循环冗余校验码)校验处理，以判断升级包是否正确及完整，若是，则终端设备根据升级包进行升级，并运行新固件。

其中，CRC是数据通信领域中最常用的一种查错校验码，其特征是信息字段和校验字段的长度可以任意选定，CRC是一种数据传输检错功能，对数据进行多项式计算，并将得到的结果附在帧的后面，接收设备也执行类似的算法，以保证数据传输的正确性和完整性。

然而，即使是在本实施例中所揭示的快速OTA的升级方法，也会持续大概1个小时，难免会在升级过程中遇到一些异常情况，例如终端设备和协调器断开连接，即在升级过程中如果升级中断，此时，终端设备保存当前的升级进度，并将当前的升级进度写到EPPROM里面去，最终会进入休眠状态，在下次Zigbee网络连接正常，即在终端设备和协调器恢复连接，且终端设备被唤醒时，终端设备获取当前的升级进度，并根据当前的升级进度继续进行升级，即终端设备能够接续上次升级的进度重新开始升级，实现了断点续传。

本实施例在终端设备被唤醒时，终端设备将事件包发送给协调器；协调器根据事件包中的终端设备的短地址与设备类型，来判断本地是否有与终端设备对应的升级包；若存在，则协调器发送通知包给终端设备，终端设备从通知包中获取当前版本号、设备ID、固件类型，并判断获取的信息与通知包的类型是否匹配；若判断到当前固件的类型与通知包的类型匹配，则终端设备设置禁止进入休眠状态的标志位，并发送升级请求包给协调器，避免了终端设备在OTA升级过程中休眠，保证了OTA升级过程的连续，协调器向终端设备发送成功状态的回复包后，终端设备发送块请求给协调器，协调器根据升级请求包向终端设备传输升级包，当终端设备检测到接收的升级包大小与回复包中升级包的大小相匹配时，终端设备向协调器发送结束请求包，以使协调器接收到结束请求包时，向终端设备发送结束回复包，终端设备接收到接收回复包后对升级包进行CRC检测，若检测结果成功则根据升级包对固件进行升级，能够实现OTA快速升级，减少了OTA升级所持续的时间，保证终端设备固件版本及时更新的效果。

上述方法应用于系统中，其逻辑过程通过计算机程序来表示，并具体通过系统实现。

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

对于系统的硬件结构，请参阅图3，图3是本申请一种OTA升级的系统一实施例的结构示意图。本实施例OTA升级的系统100包括系统包括终端设备101以及协调器102。

具体来说，在终端设备101被唤醒时，终端设备101将事件包发送给协调器102；协调器102根据事件包判断是否有与终端设备101对应的升级包；若是，则协调器102发送通知包给终端设备101，终端设备101获取当前固件的类型，并判断当前固件的类型与通知包的类型是否匹配；若判断到当前固件的类型与通知包的类型匹配，则终端设备101设置禁止进入休眠状态的标志位，并发送升级请求包给协调器102；协调器102根据升级请求包向终端设备101传输升级包；终端设备101根据升级包进行升级。

对于OTA升级的系统执行OTA升级的方法，本实施例系统可以执行上述方法中终端设备以及协调器执行的步骤。相关内容请参见上述方法中的详细说明，此处不做赘述。

本实施例一种OTA升级的系统能够使终端设备快速OTA升级，减少了OTA升级所持续的时间，有保证终端设备固件版本及时更新的效果。

以上仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

1.一种OTA升级的方法，其特征在于，应用于终端设备和协调器，所述方法包括：

在所述终端设备被唤醒时，所述终端设备将事件包发送给所述协调器；

所述协调器根据所述事件包判断是否有与所述终端设备对应的升级包；

若是，则所述协调器发送通知包给所述终端设备，所述终端设备获取当前固件的类型，并判断所述当前固件的类型与所述通知包的类型是否匹配；

若判断到所述当前固件的类型与所述通知包的类型匹配，则所述终端设备设置禁止进入休眠状态的标志位，并发送升级请求包给所述协调器；

所述协调器根据所述升级请求包向所述终端设备传输升级包；

所述终端设备根据所述升级包进行升级。

2.根据权利要求1所述的方法，其特征在于，所述协调器根据所述事件包判断是否有与所述终端设备对应的升级包包括：

所述事件包包括所述终端设备的设备类型，所述协调器判断是否有与所述设备类型对应的升级包。

3.根据权利要求1所述的方法，其特征在于，所述升级请求包至少包括版本号，在所述协调器根据所述升级请求包向所述终端设备传输升级包之前，所述方法进一步包括：

所述协调器判断所述升级包的版本号是否与所述升级请求包的版本号匹配；

若判断到所述升级包的版本号与所述升级请求包的版本号匹配，则所述协调器向所述终端设备发送包括OTA＿STATUS＿SUCCESS状态以及所述升级包的大小的回复包，所述OTA＿STATUS＿SUCCESS状态用于显示升级请求成功；

若判断到所述升级包的版本号与所述升级请求的版本号未匹配成功，则所述协调器向所述终端设备发送包括OTA＿STATUS＿NO＿IMAGE＿AVAILABLE状态的回复包，所述OTA＿STATUS＿NO＿IMAGE＿AVAILABLE状态用于显示升级请求失败。

4.根据权利要求3所述的方法，其特征在于，在所述终端设备接收到所述包括OTA＿STATUS＿SUCCESS状态的回复包时，所述终端设备发送块请求给所述协调器；

所述协调器根据所述块请求获取所述升级包，并向所述终端设备传输所述升级包；

在所述终端设备接收到所述包括OTA＿STATUS＿NO＿IMAGE＿AVAILABLE状态的回复包时，所述终端设备进入所述休眠状态。

5.根据权利要求1所述的方法，其特征在于，所述终端设备根据所述升级包进行升级之前，包括：

当所述终端设备检测到接收的所述升级包大小与所述回复包中所述升级包的大小相匹配时，所述终端设备向所述协调器发送结束请求包；

所述协调器接收到所述结束请求包时，向所述终端设备发送结束回复包。

6.根据权利要求5所述的方法，其特征在于，所述终端设备根据所述升级包进行升级，包括：

所述终端设备接收所述结束回复包，并对所述升级包进行CRC校验处理，以判断所述升级包是否正确及完整；

若是，则所述终端设备根据所述升级包进行升级。

7.根据权利要求1所述的方法，其特征在于，所述终端设备和所述协调器通过Zigbee协议建立通信。

8.根据权利要求1所述的方法，其特征在于，所述方法进一步包括：在所述终端设备和所述协调器断开连接时，所述终端设备保存当前的升级进度；

在所述终端设备和所述协调器恢复连接，且所述终端设备被唤醒时，所述终端设备获取所述当前的升级进度，并根据所述当前的升级进度进行升级。

9.一种OTA升级的系统，其特征在于，所述系统包括终端设备以及协调器；其中，

在所述终端设备被唤醒时，所述终端设备将事件包发送给所述协调器；

所述协调器根据所述事件包判断是否有与所述终端设备对应的升级包；

若是，则所述协调器发送通知包给所述终端设备，所述终端设备获取当前固件的类型，并判断所述当前固件的类型与所述通知包的类型是否匹配；

若判断到所述当前固件的类型与所述通知包的类型匹配，则所述终端设备设置禁止进入休眠状态的标志位，并发送升级请求包给所述协调器；

所述协调器根据所述升级请求包向所述终端设备传输升级包；

所述终端设备根据所述升级包进行升级。

10.一种存储设备，其特征在于，所述存储设备用于存储程序数据，所述程序数据能够被执行以实现权利要求1－8中任一项所述的方法。