LoRaWAN 规范1.0 （章节10~13）
LoRaWAN 规范1.0 （章节10~13）
最近在做LoRa， LoRaWAN协议略微复杂，边读边翻译，现在把部分关键的翻译分享给各位做物联网的同行。
当然里面掺杂了一些我的个人笔记，希望对大家有所帮助。
如果哪里有问题，欢迎应各位留言或者邮件指正。翻译很辛苦，转载请注明出处和源链接
- 英文原文链接： 《LoRaWAN Specification 1R0》
- LoRaWAN版本历史及协议格式说明
- 翻译原文链接：
章节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 |
信标在空中传输的时间远远小于信标为网络管理广播帧预留的时间。
信标窗口时间间隔分成
终端设备一旦使用第 N 个时隙，就必须精确的在信标起始之后的第 Ton 秒打开接收窗口，其中Ton计算方法如下：
N是时隙索引（第N个时隙），单位ms。
最后一个ping slot在上次信标开始之后的第
13.2 随机时隙
为了避免系统冲突和 over-hearing (不确定是窃听还是过载，不过根据LoRWAN的功能推断这里应该是过载)，使用随机的时隙索引，并且每个信标期间都要变化。
参数如下：
| DevAddr | 设备单播或组播网络地址，32位 |
|---|---|
| pingNb | 每个信标周期内的ping slot数量。必须是2的指数倍： |
| pingPeriod | Period of the device receiver wake-up expressed in number of slots： |
| 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 中国大陆许可协议进行许可。
