LoRaWAN 规范 1.0（2~4章）

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

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

鉴于本人在阅读现代国人的译文时的所感所想：

在本文档的译文中不会出现任何音译，也尽量减少让人不懂的直译，转成符合中国人逻辑的文字。我不懂或者不确定的地方会将原文一起放上，如果有误还请大家指出来。

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

LoRaWAN 规范 1.0 （2~4章）

声明

本文翻译版本已更新至LoRaWAN 1.0.2，同时修正了一些错误，与初始版本相比有些内容变动较大。

请注意本文中的带上标的引用、说明

2 LoRaWAN 简介

LoRa^TM 是由Semtech开发的一种远距离、低功耗、低速率的无线射频技术。本文档中，将具有比A类更多功能的设备统一称为 “高类终端设备”。

原文：
Devices implementing more than Class A are generally named “higher Class end-devices” in this document.

2.1 LoRaWAN Classes

• 终端双向通信（A类）

  A类的终端设备每次发送数据后会打开两个持续时间很短的接收窗口来接收下行数据，终端设备通过这种方式实现双向通信。传输时间间隔等于终端设备基础的时间间隔加上一个随机时间（ALOHA类型协议）。对终端设备来说，A类是功耗最低的系统，只有在发送数据后的一小段时间内接收处理服务器发送来的数据。服务器在其它所有时间上的下行数据必须等待节点下一次发送数据才可以下发。

  通过随机时间对间隔进行微调来实现随机访问，让所发送者平等、自由地竞争信道的使用权。

  低功耗，先发送后接收，发送和接收交替进行。终端只有在发送数据后才能接收处理服务器发送来的数据，发送数据不受接收数据的影响。收发比=1：1

• 具有接收时隙的终端双向通信（B类）

  B类终端设备允许更多的接收窗口。在A类接收窗口的基础上B类设备还会在特定的时刻打开更多的接收窗口。而为了保证终端设备能够在特定的时间打开接收窗口，它会从网关接收信标来完成时间同步。这样服务器也就可以获知终端设备的所有接收窗口的时刻。

  同样是先发送后接收，不同的是每次发送后按照一定时间间隔启动接收窗口，接收多条数据。时间间隔从网关获取，以便服务器知晓终端接收消息的时刻。收发比=1：N

• 最大接收时隙的终端双向通信（C类）

  C类终端设备的接收窗口，除了在发送数据的时候关闭外一直处于打开状态。C类终端功耗比A类和B类都大，但对于和服务器之间的交互来说延迟也最低。

  打开接收窗口的时间间隔很小，几乎不间断的接收消息。比A和B更耗能，但和服务器交互的延迟低。

　2.2 规范

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

注意：

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

3 物理层消息格式

LoRa中用来区分上行和下行消息。

3.1 上行链路消息

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

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

Uplink PHY:

3.2 下行链路消息

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

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

下行链路消息：

3.3 接收窗口

设备终端每次发送数据完成后打开两个收窗口。以数据发送结束作为基准进行计算接收窗口的开启时间。

           发送           |                             | RX1                       | RX2
|<---------------------->|<--------------------------->|                           |
|      无线发送耗时        |  RECEIVE_DELAY1             |                           |
|                        |<------------------------------------------------------->|
                                                            RECEIVE_DELAY2

3.3.1 第一个接收窗口的 开启、使用的信道和数据速率

第一个接收窗口(RX1)使用的频率、数据速率与上行传输时使用的频率、数据速率存在映射关系。RX1在发送完成后第RECEIVE_DELAY1秒（+/- 20 毫秒）开启。并且收发数据使用的数据速率和地域有关，详情资料在文档《LoRaWAN 区域相关参数手册》（LoRaWAN Regional Parameters document）。默认情况下第一个接收窗口数据速率和最后一次发送数据时使用的速率相同。

3.3.2 第二个接收窗口的 开启、使用的信道和数据速率

第二个接收窗口RX2使用经过修正的可配置的 经过配置的固定的 频率和数据速率。RX2在发送完成后第RECEIVE_DELAY2秒（+/- 20 毫秒）开启。频率和数据速率可以通过MAC命令修改（见第5章）。默认的频率和数据速率与地域相关，详情资料在文档《LoRaWAN 区域相关参数手册》（LoRaWAN Regional Parameters document）。

3.3.3 接收窗口持续时间

接收窗口的最短时间必需满足：终端设备的无线收发器能够处理完下行数据的前导码。

3.3.4 接收期间接收者的活动

无线电接收器在某个接收窗口检测到相应的前导码后会继续接收，直到下行数据帧全部解调完毕。如果在第一个接收窗口检测并完成解调，同时通过检查地址（服务器分配的地址）和MIC，确认该帧属于本节点，终端设备不再打开第二个接收窗口。

3.3.5 服务器给终端设备发送消息

服务器必需要十分精确的在这两个接收窗口的时间点上发送数据终端设备才能收到。

3.3.6 接收窗口相关的重要事项

上一次发送结束后，在没有收到数据或者第二个没有关闭前，不能再次发送。

3.3.7 其它协议数据的收发

节点可以通过LoRaWAN收发窗口监听或传输其它协议，或者做任何传输。收发其它协议或者在LoRaWAN收发窗口之间传输任何数据。 不过，终端设备仍然要遵守当地法律法规并且遵循LoRaWAN规范。

4 MAC 消息格式

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

4.1 MAC 层 (PHYPayload)

大小（字节）	1	1..M	4
PHYPayload	MHDR	MACPayload	MIC

MACPayload字段长度M的最大值与区域有关，详细见第六章。

4.2 MAC 头 (MHDR 字段)

第几位(Bit)	7..5	4..2	1..0
MHDR	MType	RFU	Major

MAC 头（MHDR）的 MType 表示消息类型；Major 表示LoRaWAN主版本号，指明帧格式所遵循的编码规则。

• 4.2.1 消息类型 (MType 字段)

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

  MType	说明	备注
  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 请求入网和同意入网

  请求入网和同意入网的消息在OTA激活过程中使用，具体见章节6.2

  这里翻译成请求入网和同意入网，节点发送数据的动作会在下面翻译成 入网请求。

• 4.2.1.2 数据

  消息数据既可以传输MAC命令也可以传输应用数据，甚至可以一起发送。接收者对需要确认的消息 （confirmed-data message） 必须做出回复，而对于 不需要确认的消息 （unconfirmed-data message）则不需要对其回复5。私有消息（或者说专有消息，指用户自定义的消息，英文：Proprietary messages）用来实现 非标准 的消息，不能与标准协议格式互通，但设备之间要都能理解这些私有扩展。

  不同消息类型用不同的方法保证一致性，下面会介绍这一点。

• 4.2.2 主版本号（Major 字段)

  Major bits	说明
  00	LoRaWAN R1
  01..11	保留（RFU）

  注意：

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

  (e.g., as part of the device personalization information).

4.3 MACPayload

MAC 荷载，也就是所谓的“帧数据”，包含：帧头（FHDR）、端口（FPort）以及帧荷载(FRMPayload），其中端口和FRMPayload可配置（可变）。

• 4.3.1 帧头(FHDR)

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

  FCnt 下面章节有详细说明

  大小（字节）	4	1	2	0…15
  FHDR	DevAddr	FCtrl	FCnt	FOpts

  下行 数据帧帧头的FCtrl结构如下：

  第几位	7	6	5	4	[3..0]
  FCtrl	ADR	RFU	ACK	FPending	FOptsLen

  上行 数据帧帧头的FCtrl结构如下：

  第几位	7	6	5	4	[3..0]
  FCtrl	ADR	ADRACKReq	ACK	RFU	FOptsLen

• 4.3.1.1 帧头中的数据速率自适应控制 (FCtrl中的ADR, ADRACKReq )

  LoRa网络允许终端设备逐一使用所有可用的数据速率。LoRaWAN协议根据该特性对静态终端6的数据速率进行调整优化，这就是数据速率自适应(ADR)。ADR可用时，网络会对速率进行优化，使其使用的数据速率尽可能快。

  当无线电信道持续、快速地衰减时，数据速率自适可能无法使用。当网络不能控制设备数据速率时，设备的应用层就要对其进行控制。建议这种情况下最好把所有数据速率都尝试一下。应用层应该一直尝试在给定网络条件下，使空中时间总耗时最少。

  如果ADR设置为1，服务器可以通过MAC命令控制设备的数据速率。如果ADR设置为0，无论接收的信号的质量如何，服务器都不对终端的数据速率做任何调整。由终端设备或网络决定是否使用该位。不过，只要条件允许就应该开启ADR，这样可以延长终端的电池寿命、充分利用网络带宽。

  注意：

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

  如果终端的数据速率经过网络优化比最低速率大，那节点就要定期检查保证服务器仍然能够收到上传的数据。 终端上行的帧计数器每递增一次（重传时计数器不递增）的同时，设备的 ADR_ACK_CNT 计数器也递增。如果 ADR_ACK_LIMIT (ADR_ACK_CNT >= ADR_ACK_LIMIT)次上行之后没有收到下行回复，就会设置 ADR 请求响应位（将 ADRACKReq 设为1）。此时要求网络在接下来的 ADR_ACK_DELAY 次上行之内做出响应，在任何一次上行后收到下行数据，节点都会重置计数器 ADR_ACK_CNT。在此期间的下行数据不需设置ACK位，因为终端在等待接收期间收到任何应答都表示网关还能接收来自该设备的上行数据。如果在接下来 ADR_ACK_DELAY 次之内（比如：总共发送次数 ADR_ACK_LIMIT + ADR_ACK_DELAY）没有收到回复，就切换到更低的数据速率上，以获得更远的射频传输距离，并重复上述过程7。终端设备每达到 ADR_ACK_DELAY 就会再次降低自己的数据速率。如果设备正在使用默认的数据速率就不再设置 ADRACKReq ，这种情况下传输距离已经最大，任何操作都不会有改善。

  注意：

  不要求网络立刻回复 ADR 请求，要给网络留出足够的反应时间，以便网络给出最佳的下行链路的调度方案。

  注意：

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

• 4.3.1.2 消息确认位和确认流程 (FCtrl中的ACK)

  收到confirmed类型的消息时，接收者要回复一条设置了确认位的消息（ACK 设为1）。如果发送者是终端，网络就把确认消息发送到该终端打开的接收窗口。如果发送者是网关，确认消息的发送由终端就自行判断。

  确认消息只会在收到消息以后作为响应发送，并且不重发。

  注意：

  终端处理越简单越好、状态越少越好，因此设备收到需要确认的消息后要立刻回复，回复的消息要简明扼要（最好发空消息）。回复也可以延缓，放到下一条正常消息里面一起发送。

  笔记：

  这就是说Confirmed消息单独的回复只能是Unconfirmed，同时设置ACK标记。和正常消息一起发送的话没有限制。

• 4.3.1.3 重传机制

  如果终端设备发送一条需要确认的消息后没有收到响应，终端就会重新发送这条消息。不同设备间的消息重传的次数以及传输的时间可能不同。

  注意：

  第18章给出了确认机制的时序图

  注意：

  如果设备重传次数到限制后仍然没收到确认消息，就会降低自身的数据传输速率来增加传输距离，并再次尝试连接。该消息是再次重传还是丢弃该消息继续运行，由终端自己决定。

  注意：

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

  注意：

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

• 4.3.1.4 帧挂起位 (FPending in FCtrl, downlink only)

  帧挂起位（FPending）只在下行交互中使用，表示网关还有数据挂起等待下发。此时要求终端尽快发送上行消息来再打开接收窗口。

  FPending的详细用法在18.3章。

• 4.3.1.5 计数器 (FCnt)

  每个终端有两个计数器：上行链路计数器（FCntUp），其值的增加由终端控制，从终端发往服务器；下行链路计数器（FCntDown），其值的增加由服务器控制，从服务器发往终端。网络服务器记录上行帧，并且为每个节点创建下行计数器。一次 JoinReq – JoinAccept 消息交换之后，或者个性化的终端设备8重置之后，终端设备上的计数器9以及网络服务器上该终端设备对应的计数器都会重置为0。之后每次其中一方发送一条新的数据帧，发送方所控制的 FCntUp 或 FCntDown 就会加1。接收方对应的计数器在检查通过后则会与之保持同步。在考虑到计数器回滚的情况下，如果收到的增加过的计数器与本地现有计数器的值之差小于指定的值 MAX_FCNT_GAP10，则检查通过；如果两者之差大于 MAX_FCNT_GAP 就表示丢失了过多的数据包，（该数据帧）随后被丢弃11。不需要确认的帧多重传输（见参数 NbTrans 的说明）时，或者需要确认的帧没有收到确认回执时，这两种情况下FCnt不会增加。

  笔记：

  上行链路计数器（FCntUp），由终端产生并维护，记录发往服务器的帧数量；下行链路计数器（FCntDown），由服务器产生并维护，记录服务器发往终端的帧数量。

  笔记：

  原文中说了 计数器之差MAX_FCNT_GAP和小于MAX_FCNT_GAP的情况怎么处理，没有说明等于的情况怎么处理。不过通过阅读节点源代码可以知道，等于的情况与小于的情况处理方式相同，即分为 =< MAX_FCNT_GAP 和 > MAX_FCNT_GAP两种情况。但是为了尊重原文，在这里做出说明而不在原文译文中改动。

  LoRaWAN的帧计数器可以是16位（2字节），也可以是32位（4字节）。指定终端设备需要通过带外数据12通知网络端设备自己使用的帧计数器的位宽。如果使用 16位帧计数器， FCnt字段可以直接当做计数器的值，有需要的话可以通过在前面填充0（值为0）字节来扩展。如果使用 32-bits 帧计数器，FCnt字段对应32位计数器的16个最低有效位（换句话说，FCntUp用来发送上行数据帧，FCntDown用来发送下行数据帧）。

  应用会话密钥和网络会话密钥不变的情况下，除重传外，终端设备不能重复使用同一个FCntUp。

  注意：

  由于 FCnt 是32位帧计数器中16个最低有效位的值，因此服务器必须通过观察数据交互来自己推断帧计数器的16个最高有效位。

• 4.3.1.6 帧配置 (FOptsLen in FCtrl, FOpts)

  帧配置长度（FOptsLen）字段位于帧的 FCtrl 部分，表示FOpts的实际长度。FOpts字段用来传输MAC命令，最长15字节，可以为空。一系列MAC命令的详细解释在第5章。

  如果FOptsLen=0，FOpts为空。如果 FOptsLen≠0 ，即MAC命令放在FOpts字段，端口号不能为0（FPort要么为空，要么是一个非零值）。

  MAC命令不能同时出现在FRMPayload和FOpts中，万一出现了，设备应丢掉该帧数据。

• 4.3.2 端口（FPort）

  帧负载数据（FRMPayload）不为空的时候端口号也不能是空。此时FPort=0表示FRMPayload中只有MAC命令（详情见章节4.4）。1…223（0x01…0xDF）范围内的FPort由应用指定； FPort = 224 专门为LoRaWAN Mac层测试协议服务。

  注意：

  FPort = 224 的目的是：专门用来通过无线方式在最终版本的终端设备上进行Mac方案的合理性测试，从而在实际场景中不必依赖于特定测试版本的设备。测试和正常操作不能同时进行，但该Mac层实现属于设备正常应用。测试协议使用AppSKey加密，这样可以保证在设备拥有者没有参与的的情况下，网络无法擅自开启设备的测试模式。如果在已经连接到正常网络的设备上运行测试，而网络侧的 测试应用 通过这种方式获取到AppSKey，这就不属于LoRaWAN协议的范围了。如果在专门的测试平台（不是正常网络）上通过OTAA进行测试，并且为了保证入网成功将AppKey告诉了测试平台，这也不属于协议范围。

  原文：
  The purpose of Fport value 224 is to provide a dedicated Fport to run Mac compliance test scenarios over-the-air on final versions of devices, without having to rely on specific test versions of devices for practical aspects. The test is not supposed to be simultaneous with live operations, but the Mac layer implementation of the device shall be exactly the one used for the normal application. The test protocol is normally encrypted using the AppSKey. This ensures that the network cannot enable the device’s test mode without involving the device’s owner. If the test runs on a live network connected device, the way the test application on the network side learns the AppSkey is outside of the scope of the LoRaWAN specification. If the test runs using OTAA on a dedicated test bench (not a live network), the way the Appkey is communicated to the test bench, for secured JOIN process, is also outside of the scope of the specification.

  225..255 (0xE1..0xFF)保留，以便未来对标准化应用进行扩展。

  大小（Bytes）	7..22	0..1	0..N
  MACPayload	FHDR	FPort	FRMPayload

  N是FRMPayload的字节数，N的取值范围见LoRaWAN 区域性参数手册。

  N的范围：

  N≤M−1−length(FHDR)

  其中M是MACPayload的最大长度。length(FHDR)是FHDR的字节长度。

• 4.3.3 MAC 帧负载据加密（FRMPayload）

  如果帧数据中包含payload，要先对FRMPayload进行加密，再计算消息的一致性校验码（MIC）。

  加密方案使用基于IEEE 802.15.4/2006 Annex B [IEEE802154] 的AES加密，秘钥长度128位。

  使用哪种加密秘钥K取决于消息的FPort：

  FPort	K	备注
  0	NwkSKey	网络密钥
  1..255	AppSKey	应用密钥

  加密字段： 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加密，得到S的块队列Si：

  

  通过分割对payload进行加解密：

  

• 4.4 消息一致性校验码 (MIC)

  对整个消息的所有字段进行计算（AES签名算法CMAC）得到消息一致性校验码（MIC）。

  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

PS

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

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

---

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

---

1. See the LoRa radio transceiver datasheet for a description of LoRa radio packet implicit/explicit modes. ↩
2. 本文档对”服务器发往多个节点的组播消息的传输“不做说明。 ↩
3. 空载数据的一致性校验在本层完成，使消息的发送时间尽可能短，使它在任何占空比下对ISM频段的影响降低都到最低。 ↩
4. payload大小的最小值在第六章有详细介绍。 ↩
5. 确认机制详细的时序图在第18章 ↩
6. 静态终端指的是静止状态的终端设备，位置不发生变化。与位置经常变化的移动终端相对。 ↩
7. 原文说的是 “regain connectivity” ，可能是重新入网也可能是重新发送正常数据。阅读节点源码，这里是“重新发送正常数据”。 ↩
8. JoinReq – JoinAccept 也就是OTAA入网成功，个性化终端设备也就是各项参数通过人工配置进行激活的终端设备，即我之前翻译中的 手动激活 的设备。 ↩
9. 这里使用复数，而没有指明上行计数器还是下行计数器，说明两个计数器都会被影响。 ↩
10. MAX_FCNT_GAP、 RECEIVE_DELAY1 以及 RECEIVE_DELAY2 的值 可以从 * LoRaWAN1.0.2参数文档 * 找到。鬼知道原文备注的“Error! Reference source not found. for EU863-870 or Error! Reference source not found. for US902-928.” 是不是超链接的时候没找到。 ↩
11. 这里之前翻译为 “这条以及后面的数据就被丢掉”，不太准确。因为在考虑到DevAddr可能重复的情况下，错误数据可能来自另一个节点，而随后本节点真正过来的数据不一定是错误的。目前LoRaWAN开发者（包括公司）各自开发，Network ID随意设置并没有遵循LoRa联盟的规则，因此不同的节点DevAddr是有可能相同的。哪怕不考虑这些，DevAddr中的NetID只取7位，才128个不同的DevAddr地址空间，理论上也是可能出现重复的。 ↩
12. Out-Of-Band维基百科、Out-Of-Band百度百科 ↩