[分享] 【转】LoRaWAN 规范 1.0 （2~4章）

最近在做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）
    
  
  

PS3: 前段时间图片外链挂了，现在已更新

• 终端双向通讯（A类）
  低功耗，先发送后接收，发送和接收交替进行。终端只有再发送数据后才能接收处理服务器发送来的数据，发送数据不受接收数据的限制。收发比=1：1
• 具有接收时隙的终端双向通讯（B类）
  同样是先发送后接收，不同的是每次发送后按照一定时间间隔启动接收窗口，接收多条数据。时间间隔从网关获取，以便服务器知晓终端接收消息的时刻。收发比=1：N
• 最大接收时隙的终端双向通讯（C类）
  打开接收窗口的时间间隔很小，几乎不间断的接收消息。比A和B更耗能，但和服务器交互的延迟低。
  
  

高级类的附加功能向下兼容低级类。所有LoRaWAN终端必须实现A类的功能。

注意：

本规范手册中：物理消息格式、MAC消息格式以及A类和其它高级类都具备的东西，只在本手册的A类部分介绍。

LoRa中区分上行和下行的术语。

上行链路消息由终端发送经过一个或多个网关中转到达网络服务器。

它使用的LoRa无线分组显性模式由物理头（PHDR）和它的CRC（PHDR_CRC）校验组成。负载的一致性（发送和接收的数据完全一致，不仅仅是完整）由CRC保证。

Uplink PHY:

下行链路消息由网络服务器发送给终端设备，每条消息对应的终端设备是唯一确定的，而且只通过一个网关中转。

下行链路消息由物理头（PHDR）和这个头的CRC（PHDR_CRC）组成。

下行链路消息：

设备终端每次发送数据（上行传输）后打开两个短接收窗口（short receive windows）。接收窗口的启动时间是配置好的时间周期，该时间在最近一条上行传输比特数据的结尾。

LoRa所有的上下行链路消息都会包含PHY负载，该负载以单字节MAC头为开始，MAC头后面是MAC负载，结尾是4字节的消息一致码（MIC）。

MACPayload字段长度M的最大值见第六章。

MAC 头中包含消息类型（MType）和帧编码所遵循的LoRaWAN规范的主版本号（Major）。RFU是保留位。

• 4.2.1 Message type (MType bit field)
  

LoRaWAN自定义了六个独特的MAC消息类型：join request, join accept, unconfirmed data up/down, 以及 confirmed data up/down

• 4.2.1.1 Join-request and join-accept messages
  已经添加上表的到备注
• 4.2.1.2 Data messages
  消息数据既能传输MAC命令又能传输应用数据，甚至可以一起发送。不同消息类型用不同的方法保证一致性，下面会介绍这一点。
• 4.2.2 Major version of data message (Major bit field)
  
  

注意：

主版本号指明激活过程中(in the join procedure)使用的消息格式（章节6.2）和MAC Payload前4字节（第4章）。终端要为每个不同的主版本号实现不同子版本的消息格式。终端使用的主版本号应当提前发送给网络服务器,可以作为其它消息的一部分捎带发送，如，设备个性化信息。

MAC 荷载，也就是所谓的“数据帧”，包含：帧头（FHDR）、可配置的端口字段（FPort）以及可配置的帧负载字段（FRMPayload）

• 4.3.1 Frame header (FHDR)
  

FHDR由：终端短址（DevAddr）、一个帧控制字节（FCtrl）、2字节的帧计数器（即帧大小，FCnt） 和 最多15个字节的配置（FOpts，用来传输MAC命令）组成。

• 4.3.1.1 帧头中的自适应数据速率控制 (ADR, ADRACKReq in FCtrl)
  LoRa网络对终端的数据速率没有任何限制。LoRaWAN协议通过该特性调整优化静态终端（相对移动终端来讲）的数据速率，即自适应数据速率（Adaptive Data Rate (ADR)）。ADR可用时，网络会为其优化来使用尽可能快的数据速率。
  移动终端在移动过程中会快速切换无线广播环境，该过程中进行数据速率管理没什么实际意义，此时移动终端应使用已经修正过的默认数据速率。
  设置ADR之后，网络通过MAC命令控制终端的数据速率。如果没有设置ADR，网络会无视收到的信号的质量，不对终端的数据速率做任何调整。终端或网络用不用ADR要根据需求决定。不过，只要条件允许就应该开启ADR，这样可以延长终端的电池寿命并充分利用网络带宽。
  注意：

  哪怕移动终端在大多数时间下都是不移动的。因此终端可以根据它自己移动状态请求网络通过ADR进行数据速率优化。

  如果终端的数据速率经过网络优化比默认值大，那他就要定期检查保证网络能够收到上传的数据。 终端上行的帧号每增加一次（重复发送不增加帧号），同时ADR_ACK_CNT + 1。上行帧号达到ADR_ACK_LIMIT（ADR_ACK_CNT >= ADR_ACK_LIMIT）仍然没有收到回复，就设置ADR请求应答标记（ADRACKReq）。接下来向网络发送请求，如果在发送上行请求后的一定时间 ADR_ACK_DELAY 内收到服务器下行帧的回应则重置ADR_ACK_CNT数量。在此期间不需设置下行ACK位，因为在终端等待接收期间（接收时隙内）收到任何应答都意味着网关还会接收来自该设备的上行数据。如果终端在下一个上行链路 ADR_ACK_DELAY （例如，一共过了时间：ADR_ACK_LIMIT + ADR_ACK_DELAY)）内没有收到任何回复， 就会尝试切换到更低的数据速率上（无线广播范围的距离更长）再次连接，每次终端设备达到 ADR_ACK_LIMIT 就会再次降低自己的数据速率。 如果设备使用默认的数据速率就不需要设置 ADRACKReq ，因为这种情况下任何操作都不会改善连接范围（增加连接距离）。
  注意：

  为了让网络对下行链路给出最佳的调度方案，不要要求对 ADR 请求立刻做出应答，要给网络留足时间。

  注意：

  上行传输时，如果 ADR_ACK_CNT >= ADR_ACK_LIMIT 并且当前数据速率比设备的最小数据速率高，就要设置 ADRACKReq，其它情况下不需要。

• 4.3.1.2 消息确认位和确认流程 (ACK in FCtrl)
  收到confirmed类型的消息时，接收者要回复一条确认消息（ACK，通过设置确认位实现）。如果发送者是终端，网络就把消息发送到该终端打开的接收窗口。如果发送者是网关，终端就自行决定发送确认消息的传输方式。
  确认消息只会在收到消息以后作为响应发送，并且不重发。
  注意：

  为了尽量简化终端处理、减少状态，一旦收到需要确认的消息要立刻发送确认消息，确认消息要简单直接（最好发空消息）。

• 4.3.1.3 重传机制（Retransmission procedure）
  如果终端设备发送一条需要确认的消息后没有收到响应，终端就会重新发送这条消息。不同设备间的消息重传的次数和每次的时间可能不同，当然这些也可以通过网络服务器调节。
  注意：

  18章给出了一些确认机制的时间

  注意：

  如果设备重传次数到限制后还没收到确认消息，就会降低自身的数据传输速率来增加连接距离再次尝试连接。这种条消息的重传或者放弃是由终端决定的。

  注意：

  如果网络服务器重传次数达到限制后还没有收到确消息，在没有收到设备的消息之前会认为无法与终端建立连接（终端不可达）。这种消息的重传或者放弃是由服务器决定的。

  注意：

  上面提到的重传期间的数据速率回归机制在18.4有详细介绍

• 4.3.1.4 帧挂起位 (FPending in FCtrl, downlink only)
  帧挂起位（FPending）只在下行交互中使用，表示网关还有数据挂起等待发送。此时需要终端尽快发送上行消息来再打开一个接收窗口。
  FPending的详细用法在 18.3。
• 4.3.1.5 计数器 (FCnt)
  每个终端有两个计数器：上行链路计数器（FCntUp），由终端产生并维护，记录发往服务器的帧数量；下行链路计数器（FCntDown），由服务器产生并维护，记录服务器发往终端的帧数量（此处与我们当前的设备服务器与设备的交互中的message id作用相同，都是为了保证消息收发一致）。终端加入服务器成功以后，终端和服务端的帧号同时置0。之后每次其中一方发送消息后，与之对应的 FCntUp 或 FCntDown 就会加1。接收方会同步保存接收数据的的帧号，对比收到的增加过的值和当前保存的值，如果两者之差小于 MAX_FCNT_GAP （要考虑号码归零，即号码达到最大值后重新从0开始），接收方就与收到的数据保持同步（更新成收到的值）。如果两者之差大于 MAX_FCNY_GAP 就说明中间丢失了很多数据然后就会丢掉这条数据。
  PS4 :感谢 ‘漠然’ 同学的邮件质疑，下面的翻译更正如下：
  LoRaWAN的帧计数器有16位和32位两种长度，两者有所不同：
  16bits时可以直接把FCnt字段的值当做帧数量使用，有需要的话可以通过前导0字节进行扩展；32bits时，会获取32bits的FCnt字段中相应的最不显著的16bits。
  16bits时，其值可以直接作为FCnt使用（反之亦然），此时有需要的话通过在前面填充0（值为0）字节（来补足）；32bits时，FCnt对应计数器的16个最低有效位（2个低字节）。上行数据使用上行FCnt，下行数据使用下行FCnt。
  使用相同的的应用会话密钥和网络会话密钥情况下，传输数据中不能使用相同的上行FCnt，除非是重传。
  注意（下面这段话译者一直没明白）：

  由于FCnt字段只携带32bits的帧数中最不显著的16bits，服务器必须通过观察流量（observation of the traffic）推断出帧号的16个最显著位。
  当计数器使用32位时，FCnt字段只发送32bits中的16个最低有效位。此时服务器需要通过观察传输的数据来自己维护16个最高有效位。

• 4.3.1.6 帧配置 (FOptsLen in FCtrl, FOpts)
  帧配置长度（FOptsLen）位于帧的 FCtrl 部分，表示FOpts的总长度。FOpts搭载到数据帧中发送的MAC命令最长15字节，详细的MAC命令见4.4。
  如果帧配置长度 FOptsLen=0，FOpts为空；如果FOptsLen不是 0，端口必须有，也不能是0（Fport=0表示MAC命令放在payload中）。 如果FOpts不为空（里面是MACommand）
  ，端口号要么省略，要么是一个非零值（具体看下面）。
  MAC命令不能同时出现在payload（负载）和帧配置项中。
• 4.3.2 端口字段 Port field（FPort）
  负载（payload）不为空的时候端口号（port）也不能是空。此时port=0表示FRMPayload中只有MAC命令（详情见章节4.4）。FPort值的可用范围是：1~223（0x01~0xDF），224～255 (0xE0～0xFF)为保留值，方便以后扩展。
  
  N是应用负载的字节数，N的取值范围见第7节
  N ≤ M - 1 - (FHDR的字节长度)
  其中M是MAC的最大有效荷载长度。
• 4.3.3 MAC 帧负载据加密（FRMPayload）
  如果帧数据中包含payload，要先对FRMPayload进行加密，再计算消息的一致码（MIC）。
  加密方案使用基于IEEE 802.15.4/2006 Annex B [IEEE802154] 的AES加密，秘钥长度128位。默认情况下，所有FPort 的加/解密都在LoRaWAN层完成；如果FPorts不为0，加/解密可以在LoRaWAN层之上完成。
• 4.3.3.1 LoRaWAN 加密
  加密秘钥K取决于消息的FPort：
  FPort
  K
  备注
  
  
  0
  NwkSKey
  网络密钥
  
  
  1..255
  AppSKey
  应用密钥
  表3，FPort列表
  加密字段： pld = FRMPayload
  采用分组加密，算法位每条消息数据定义一个块的序列,序列分为 k 块，k=ceil(len(pld)/16) （向上取整），每组用Ai表示，i=1…k，每块结构如下：
  字节数
  1
  4
  1
  4
  4
  1
  1
  
  
  Ai
  0x01
  4 × 0x00
  Dir
  DevAddr
  FCntUp 或 FCntDown
  0x00
  i
  Dir字段：上行帧为0，下行帧为1
  对Ai加密，得到Si：
  
  通过分割对payload进行加解密：
  
• 4.3.3.2 Encryption above the LoRaWAN layer
  对于选定的端口（FPort不能是0，因为0表示MAC 命令），如果LoRaWAN前面的一些层给LoRaWAN的FRMPayload是加密过的，LoRaWAN就把FRMPayload从MACPayload转发给应用，并且转发过程中不做任何改动。
• 4.4 Message Integrity Code (MIC)
  对整个消息进行MIC计算（AES签名算法CMAC），需要加密的消息包括以下字段：
  msg = MHDR | FHDR | FPort | FRMPayload
  len(msg) 表示消息的字节长度。
  MIC算法参考RFC4493：
  
  B0 定义如下：
  字节数
  1
  4
  1
  4
  4
  1
  1
  
  
  B0
  0x49
  4 × 0x00
  Dir
  DevAddr
  FCntUp 或 FCntDown
  0x00
  len(mgs)
  Dir字段：上行帧为0，下行帧为1