LoRaWAN 规范1.0 （章节10~13）

LoRaWAN 规范1.0 （章节10~13）

最近在做LoRa， LoRaWAN协议略微复杂，边读边翻译，现在把部分关键的翻译分享给各位做物联网的同行。
当然里面掺杂了一些我的个人笔记，希望对大家有所帮助。
如果哪里有问题，欢迎应各位留言或者邮件指正。

翻译很辛苦，转载请注明出处和源链接

• 英文原文链接： 《LoRaWAN Specification 1R0》
• LoRaWAN版本历史及协议格式说明
• 翻译原文链接：
  
  • LoRaWAN 规范 1.0 （章节2~4）
  • LoRaWAN 规范 1.0 （章节5）
  • LoRaWAN 规范 1.0 （章节6）
  • LoRaWAN 规范 1.0 （章节7）
  • LoRaWAN 规范 1.0 （章节10~13）

章节10~13详细讲解B类相关的知识，当然下面几章也是

10 B类模式的上行数据帧

除了帧头中FCtrl字段的保留（RFU）位，B类和A类的上行数据帧一样。B类使用A类中没有使用的RFU位：

第几位	7	6	5	4	3…0
FCtrl	ADR	ADRACKReq	ACK	ClassB	FOptsLen

上行数据中的 ClassB 位设为1，来告诉网络服务器：设备已经转换为B类模式，已经准备在照预定时间接收下行ping。

下行数据的 FPending 位意义不变，仍然表示服务器上有等待发送给设备的消息。如果下行数据使用该标记，设备应当按照A类的规范来接收数据。

11 下行Ping帧格式（B类）

11.1 物理层帧格式

和A类下行帧格式一致，不过可能要按照不同的信道频率规划。

11.2 单播和组播MAC消息

消息可以是单播，也可以是组播。给一个终端设备单独发送消息使用单播，给多个终端设备发送使用组播。组播时属于同一组的设备必须使用相同的组播地址和加密密钥。LoRaWAN B类规范并没有指定这些，这就是说要远程设置组播的组，或者安全地分发组播需要的密钥相关的信息。这些信息必须要设置，要么在节点手动激活的时候一起配置，要么通过应用层配置（远程）。

• 11.2.1单播的MAC消息格式

  单播时的，下行Ping的MAC负载（MAC payload）遵循A类规范，终端设备处理数据的方式完全相同。同时也使用相同的帧计数器，无论下行数据使用B类的 ping slot 还是使用A类的 “piggy-back” slot，计数器都会增加。

• 11.2.2组播的MAC消息格式

  组播帧和单播帧的格式只有一些微小差别：

  • 禁止携带MAC命令，不论在FOpt还是在payload（port=0）：因为组播和单播的验证稳健性不同。
  • ACK 和 ADRACKReq 必须为0，MType必须使用不需要回复的类型（Unconfirmed Data Down）。
  • 此处的FPending表示还有组播数据需要发送。一旦使用，下一次组播的接收时隙会发送一个数据帧；如果不使用，下一个组播可以带数据也可以不带数据。当接收时隙冲突时，终端可以用它来评估优先级。

12 信标捕获和追踪

终端设备由A类切换到B类之前要先接收一次网络的信标，来校正它的内部时序。终端设备进入B类模式以后，为了关闭和网络时间不一致（时基发生漂移）的内部时钟，要定期搜寻、接收网络信标。使用B类的终端有时可能会接收不到信标（超出网关连接范围、有干扰等等），
这种情况下终端设备就必须逐步扩大其信标的范围，而且 ping slots 的接收窗口也要考虑到内部时钟漂移的情况。

注：
例如，一个设备，其内部时钟精度 10ppm ，那么每个信标周期就可能会漂移 +/-1.3ms。

10ppm——每秒误差百万分之十秒，表示一天会有 10×24×60×60=0.864s的误差。

12.1 最小无信标操作时间

设备在没有信标的情况下，会维持B类模式2小时（距最后一次收到信标120分钟），这种临时的没有信标的B类操作称作“无信标”操作，这些操作都依赖终端设备自身的时钟计时。

在无信标期间，为了适应终端可能出现的时钟漂移，单播、组播和信标的接收时隙必须要逐步扩大。

12.2 建立在接收上的无信标操作扩展

在120分钟“无信标”期间，终端接收到任何信标，都会重置“无信标”时间（重新从0计算）。终端设备会通过接收到的信标来修正时间漂移，并重置接收时隙的时间长度。

12.3 时间漂移最小化

终端设备可以使用信标（如果可以的话）的精度周期性的校准它们的内部时钟，并降低内部时钟频率的误差。由于定时振荡器的时间偏移与温度相关，并且可以计算出来，因此可以通过使用温度传感器进一步降低时间漂移。

13 B类下行时隙时间

13.1 定义

为保证B类终端设备操作成功，必须要在精确的时间点开启接收时隙，该时间点与基础信标有关。本节会详细介绍这些时间。

两个信标起点之间的时间间隔称作信标周期。信标以 BEACON_RESERVED 的起点作为数据传输的起始时刻。每个信标的前面都有一段守护时间，守护时间内部不会有任何 ping slot。守护时间的时间长度和所允许的最长帧在空中的传输时间一致，以此来保证守护时间之前任何时刻开始的下行数据都能被接收完，并且不会和接收信标发生冲突。ping slot的可用时间范围：从信标预留时间的结束时刻开始，到下一个信标守护时间的起始时刻结束。

表35：信标时间

名称	时间长度
Beacon_period	128 s
Beacon_reserved	2.120 s
Beacon_guard	3.000 s
Beacon-window	122.880 s

信标在空中传输的时间远远小于信标为网络管理广播帧预留的时间。
信标窗口时间间隔分成 $2^15 = 4096$ 个时长为 30ms 的ping slots（ping时隙），这些时隙从第0个开始，至4095个结束。
终端设备一旦使用第 N 个时隙，就必须精确的在信标起始之后的第 Ton 秒打开接收窗口，其中Ton计算方法如下：

$Ton = beacon\_reserved + N \times 30$

N是时隙索引（第N个时隙），单位ms。

最后一个ping slot在上次信标开始之后的第 $beacon\_reserved + 4095 \times 30 ms = 124 970$ ms 或者 下次信标开始之前的第 3030ms 打开。

13.2 随机时隙

为了避免系统冲突和 over-hearing (不确定是窃听还是过载，不过根据LoRWAN的功能推断这里应该是过载)，使用随机的时隙索引，并且每个信标期间都要变化。

参数如下：

DevAddr	设备单播或组播网络地址，32位
pingNb	每个信标周期内的ping slot数量。必须是2的指数倍： $2^k$ 其中 $1 \leq k \leq 7$
pingPeriod	Period of the device receiver wake-up expressed in number of slots：$\frac{2 ^ {12}}{pingNb}$
pingOffset	offset是个随机值，每次信标周期开始时通过计算获得。范围： 0~(pingPeriod - 1)
beaconTime	该时间在BCNPayload中，Time of the immediately preceding beacon frame 紧接在信标帧前面的时间
slotLen	一个ping slot的时长：30ms

为了校准（对齐）接收时隙，每个信标周期终端设备和服务器都会重新计算一个伪随机偏移。随机数生成使用AES加密算法，密钥全部由0组成：

Key = 16 x 0x00
Rand = aes128_encrypt(Key, beaconTime | DevAddr | pad16
pingOffset = (Rand[0] + Rand[1]x 256) modulo pingPeriod

本信标周期内使用的缝隙：

pingOffset + N x pingPeriod 其中 N=[0:pingNb-1]

节点在以下时间点打开接收缝隙：

缝隙	开启时刻
缝隙 1	Beacon_reserved + pingOffset x slotLen
缝隙 2	Beacon_reserved + (pingOffset + pingPeriod) x slotLen
缝隙 3	Beacon_reserved + (pingOffset + 2 x pingPeriod) x slotLen
…	…
缝隙 n	Beacon_reserved + (pingOffset + (n-1) x pingPeriod) x slotLen

如果终端设备同时提供一个单播以及一个或多个组播缝隙，那么在一个新的信标周期开始时，要进行多次这种计算。为单播地址计（节点网络地址:DevAddr）算一次，为每个组播地址计算一次。

单播和组播的 缝隙 冲突时，终端设备的接收器优先处理组播。如果多个组播接收缝隙冲突，上次FPending标记位非0的优先处理。

使用随机化方案来避免单播时隙和组播时隙之间系统级别的冲突。如果在某个信标周期出现冲突，下一个信标周期几乎没有发生冲突的可能性。

PS

看到有些伙伴提问问题，由于本人的CSDN一般不在线。

为了方便交流，附个邮箱，有问题或者想法的朋友可以

---

本文由 qingchuwudi 译制，除非另有声明，在不与原著版权冲突的前提下，本作品采用知识共享署名 3.0 中国大陆许可协议进行许可。