文档
首页»文档»技术文件»固件更新无线

简介

能够通过空中进行远程固件升级(FUOTA)正在成为大多数物联网(IoT)设备的要求。任何FUOTA过程的细节都与设备使用的MCU架构紧密相连。然而,任何FUOTA系统都需要一个高效且安全的文件传递系统,以可靠地(可能)同时将固件补丁文件推送到许多设备。LoRaWAN®提供了这样一个安全可靠的文件分发系统使用组播。该服务由一组应用层包提供。本文介绍了构成LoRaWAN文件分发服务基础的两个包:“远程多播设置”包和“碎片数据块传输”包。

更新固件无线

无线更新固件是一项复杂的任务。一般涉及以下步骤:

  1. 确定需要更新的设备,并将它们放入多播组中
  2. 根据需要升级的设备平台生成二进制固件补丁文件
  3. 用私钥签名这个二进制文件,以保证完整性和真实性
  4. 将二进制文件推送到待升级设备组
  5. 每个设备验证签名以验证文件及其来源
  6. 然后每个设备安装固件更新
  7. 每台设备上报升级操作的状态(成功或失败)。这些信息由设备管理平台收集,用于监控现场设备的状态。

其中一些步骤(2、3、5和6)是针对特定设备的,并取决于许多设计选择,包括但不限于:

  • 设备MCU架构(ARM, X86等)
  • 设备内存容量
  • 设备是否使用操作系统
  • 设备是否使用安全的引导加载程序
  • 设备固件是否为部分更新而设计
  • 设备是否有加密硬件加速器

这样的限制使得不可能对每个LoRaWAN网络中的每个设备都适用的FUOTA流程进行标准化。另一个挑战是LoRaWAN网络固有的低比特率。

然而,高效和可靠的传输,以推动固件补丁通过LoRaWAN网络的一大组设备可能的。此外,LoRaWAN还具有无线多播能力。这意味着由网络传输的一个给定的无线数据包(包含固件补丁的一个片段)可能被许多设备接收。这样就不需要将补丁文件单独传输到每台设备。FUOTA over LoRaWAN通过一次将补丁文件传输到所有设备,解决了低比特率的问题。

固件更新与LoRaWAN

通过LoRaWAN, FUOTA有两个主要的应用层包:

  • 多播远程设置
  • 碎片数据块传输

这些应用层包由LoRa联盟®内的FUOTA工作组定义。规范公开可在罗拉联盟网站

图1:FUOTA的LORAWAN应用层包

在设备端,这些包位于应用层,使用LoRaWAN MAC层来传输和接收来自网络的数据包。此外,设备应用层可能同时存在其他数据包,通常也会出现一些用户应用程序代码。

设备上的每个包对应于服务器端的一个服务实现。例如,“时钟同步”与时钟同步通信服务在后端实现。在图1中,与FUOTA相关的所有后端服务被组合在一个名为“设备管理服务”的实例中。这些包中的每一个都使用不同的端口进行空中通信。这样,每个数据包对应的不同数据流在上行和下行方向都可以很容易地分离出来。

LoRaWAN多播组

在LoRaWAN网络中通过无线方式更新固件的第一步是识别和列出需要更新的设备,并将它们放入LoRaWAN多播组中。这个组可以动态创建,并通过空中设置。为此,请使用“远程多播设置”包提供的功能。

远程组播安装包

基于lorawan的网络中的每个设备都配备了单播身份,包括一个设备地址(32位)和一个单播安全上下文(一组AES128密钥),用于唯一地识别和验证网络中的设备。

这样的设备也可以属于多达四个多播组。多播组具有以下特点:

  • 多播组地址
  • 多播安全上下文
    • McAppSKey:组播应用密钥,用于对发送给组的有效载荷进行加密
    • McNwkSKey:组播网络会话密钥,用于计算发往组的报文的MIC (Message Integrity Check)字段
  • 多播帧计数器

如果一个设备是多个多播组的一部分,这些组的地址必须是不同的,以便区分它们。

组播安全上下文对于属于给定组的所有设备是相同的;但是,不同的多播组具有不同的安全上下文。他们还必须使用不同的键。

“远程多播设置”包提供了允许以下操作的命令:

  1. 查询包的实现版本
  2. 查询已分配设备的组播组列表和状态
  3. 为给定的设备创建或修改多播组
  4. 从设备上删除多播组定义
  5. 定义B类或C类广播会话,并将其与多播组关联

McGroupSetup命令允许为给定的设备创建多播组的完整上下文。该命令嵌入了一种通过空中安全传输多播组密钥的机制。这是通过传输使用特定于设备的传输密钥加密的多播密钥来实现的。它还提供了最小和最大有效帧计数器值,并通过本质上限制多播组的生存期来提高进程的安全性。

然而,创建上下文还不足以操作多播组。

基于lorawan的设备功耗低,依赖电池。这些设备通常只有在有数据传输时才会醒来,然后立即回到睡眠状态。因此,为了能够向整个组设备发送帧,系统必须首先确保组播组内的所有设备在相同的时间和相同的持续时间内都有活跃的接收器。

为了解决确保所有接收器同时处于活动状态的问题,LoRaWAN网络使用GPS时间(GPS epoch)作为时间参考(之所以选择这个时间而不是UTC时间,是因为GPS时间可以简单地用一个无符号的32位计数器表示,每秒钟加1,与闰秒无关。要深入了解闰秒,请参见https://en.wikipedia.org/wiki/Leap_second).

有不同的方法来同步基于lorawan设备的时钟到网络的时间:

  1. 设备可能会通过相应的MAC层命令DeviceTimeReq命令在LoRaWAN规范版本1.0.3及更高版本中可用)
  2. 设备可以监听周期性的B类信标,其中包含GPS时间
  3. 设备可能会使用一个名为“应用层时钟同步”的专用包。

使用哪种技术的决定将基于功耗、应用程序需求和定时精度的权衡。对这些权衡的讨论超出了本文的范围。

一旦设备时钟同步,设备管理服务必须对设备进行编程,使其同时打开接收器,并使用相同的无线电信道和数据速率。为此目的,远程组播安装包允许您定义C类或B类组播会话。

C类多播会话由开始时间、持续时间和一组无线电参数(信道和数据速率)定义。当设备的时钟时间到达开始时间时,设备使用指定的无线电参数为其无线电编程,并打开它们的接收器。然后,网络可以在C类会话的任何时刻使用相同的无线电参数广播数据包。

这种方法很简单,不需要非常精确的定时同步。设备之间几秒钟的漂移不会产生任何问题。但是,在C类会话期间,组中的设备会让它们的接收器持续打开。因此,这种方法在网络必须遵守低传输占空比的地区(例如,低于欧洲的10%)是不节能的。10%的占空比意味着设备90%的能量在C类多播会话中被浪费。

在这种情况下,包也支持使用B类多播会话。当使用B类组播会话时,组中的所有设备必须在会话开始前首先与B类信标(每128秒广播一次)同步。一旦会话开始,组中的设备将同时打开定期接收槽,并在会话期间保持打开状态。这使得这些设备可以在大部分时间睡觉的情况下使用它们的接收器。

注意:网络可能不会使用每一个可用的插槽来传输信息。然而,B类模式的实现比C类稍微复杂一些,需要网络广播B类信标。

LoRaWAN是为数不多的能够实现空中多播传输的无线电协议之一。例如,蜂窝网络通过设置与组中设备数量相同的同时单播会话来模拟多播传输。但是,在这种情况下,数据实际上会根据组中设备的数量发送多次,而不是一次。

组播远程安装包对在C类或B类组播会话期间由网络传输的数据帧的性质不作任何假设。例如,数据帧可以是单独的控制帧(例如,控制整个路灯组的开关)。

因此,在组播会话过程中,有必要实现一种有效地分割文件并确保完整地传递给组中的每个设备的方法。为此,创建了“碎片数据块传输over LoRaWAN”包。我们将在下一节对此进行讨论。

传输文件到多播组

无线多播传输的使用极大地提高了网络的效率。每一帧只传输一次,可以同时被组中的所有设备接收,而不必单独向每个设备发送相同的帧。然而,它也带来了一个挑战,即如何应对错过的招待会。考虑下面的例子:

网络将一个文件的100个片段广播给一个组播组中组装的1000个设备。无线信道受到干扰,导致每个设备随机丢失网络广播的10%的帧。如果网络传输到单个设备(单播传输),这将不是一个大问题。在这种情况下,虽然一个片段丢失时可能需要重复(大约10%的时间发生),但平均需要110次传输才能成功地将100个数据片段推送到一个设备。

然而,这在多播组中更为复杂。网络广播的第一个片段平均被1000个设备中的900个接收。这意味着100个设备没有收到第一个碎片。因此,网络再次传输它,这一次(平均)剩下的100个设备中的10个将接收它。网络第三次传输这个片段,而一个设备可能仍然会错过它。因此,平均而言,大约需要四次传输相同的数据,以确保所有设备都接收到完整的片段。只有当组中的设备数量或错误率增加时,该数字才会增加。

因此,必须使用一种不同的方法来确保所有设备接收到完整的文件,而不必多次重复每个片段。

为了克服这个问题,“碎片数据块传输”包实现了一个擦除纠正码。这种方法背后的原则是:

  1. 要发送的文件被分成多个片段N等长的片段,这样每个片段可以放入一个LoRaWAN广播有效载荷中。在我们的例子中,N= 100个相同长度的片段。
  2. 对于那些N非编码片段,使用erasure code生成N+编码片段,其中(N+米)/ N为冗余配比。冗余比必须大于我们想要补偿的丢包率,加上一个余量。在我们的示例中,假设典型的数据包丢失率为10%,那么20%的冗余配比是合适的。
  3. 这些编码片段被设计成这样一种方式,任何子集N编码片段(N + M)生成的片段可用于重建N原始文件的分片,因此保证了文件传输的完整。

同样,在我们的例子中,设备管理服务将文件分成100个片段并生成120个编码片段。然后,这120个编码片段在C类或B类组播会话期间由网络广播。每个侦听设备在会话期间可能会丢失不同的片段子集。然而,一旦设备从网络广播的120个编码片段中接收到至少100个编码片段,该设备就能够重建完整的文件。

重复方法将导致广播400帧,使用这种编码方案允许网络实现同样的成功率,而只广播120帧。

除了上述所需的编码/解码方法外,“碎片数据块传输”包还提供以下功能:

  • 查询碎片包的实现版本
  • 创建碎片会话
  • 请求一个或一组设备来提供碎片会话的状态
  • 删除碎片会话

在向一个或一组设备发送一个文件之前,必须创建一个碎片会话,向设备提供将要广播的文件的详细信息。

FragSessionSetupRequest命令附带如下参数:

  • 分片会话ID。一个设备最多可以同时有四个活动的碎片会话。此ID用于区分它们。
  • 以字节表示的片段大小。
  • 重组给定会话中传输的文件所需的片段数(从1到65535)。
  • 最后一个片段中包含的填充零的数量(如果文件长度不是片段长度的精确倍数,可能需要零。在这种情况下,零将被添加为最后一个片段长度的填充)。
  • 一个文件描述符。这是一个自由分配的四字节字段。例如,如果传输的文件是固件补丁映像,则该字段可以对传输的固件版本进行编码,从而允许在终端设备接收时进行兼容性验证。该字段的编码是特定于应用程序的。

一旦FragSessionSetupRequest命令得到组播组内所有设备的认可后,编码片段就可以传输了。

虽然多播传输在向一组设备传输相同文件时效率更高,但碎片包也允许我们使用单播下行链路发送碎片。

广播所有编码片段后,服务器可以使用FragSessionStatusRequest命令。该命令可以作为单播或多播帧发送。

设备响应此命令的信息如下:

  • 碎片会话的状态:文件成功重构,或一个错误代码,如果文件不能重新组装
  • 分片会话过程中接收到的分片总数
  • 在重新组装文件之前接收到的缺失片段的数量

额外的编码片段可能被发送到还不能完全重新组装文件的设备。这些片段可以作为单播下行链路发送,或者如果太多的设备无法重新组合文件,可以创建一个新的多播会话。

总结

本文介绍了“碎片数据块传输”和“远程组播设置”应用层包,并讨论了LoRaWAN如何提供高效、可靠的碎片文件传输服务。我们还解释了如何使用碎片文件交付服务通过无线方式向大型设备组推送二进制固件更新。这是通过使用LoRaWAN协议独特的空中多播能力与有效的片段编码方案相结合来实现的,该方案大大减少了所需的重复传输的数量。

Baidu
map