【转】LoRaWAN 规范 1.0 （2~4章）

lyzhangxiang

【转】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: 前段时间图片外链挂了，现在已更新

LoRaWAN 规范 1.0 （2~4章）2 Introduction on LoRaWAN options2.1 LoRaWAN Classes

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

　2.2 规范

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

注意：

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

3 Physical Message Formats

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

3.1 上行链路消息

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

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

Uplink PHY:

3.2 下行链路消息

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

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

下行链路消息：

3.3 接收窗口

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

4 MAC Message Formats

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

4.1 MAC Layer (PHYPayload)

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

4.2 MAC Header (MHDR field)

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

MType

Description

备注

000

Join Request

无线激活过程使用，具体见章节6.2

001

Join Accept

无线激活过程使用，具体见章节6.2

010

Unconfirmed Data Up

接受者不必回应

011

Unconfirmed Data Down

接受者不必回应

100

Confirmed Data Up

接受者必须回应

101

Confirmed Data Down

接受者必须回应

110

RFU

保留

111

Proprietary

用来实现自定义格式的消息，交互的设备之间必须有相同的处理逻辑，不能和标准消息互通

• 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)
  
  

Major bits

Description

00

LoRaWAN R1

01..11

RFU（保留）

注意：

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

4.3 MAC Payload of Data Messages (MACPayload)

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
  
  

原文链接：http://blog.csdn.net/qingchuwudi/article/details/50786289