LoRaWAN 协议规范

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 就表示丢失了过多的数据包，（该数据帧）随后被丢弃

最低0.47元/天解锁文章

「已注销」

关注

0
点赞
踩
13

收藏

觉得还不错? 一键收藏
0
评论
LoRaWAN 协议规范

罗拉规范。版权©2015罗拉联盟有限公司保留所有权利。注意使用和披露。版权©罗拉联盟,Inc .(2015)。保留所有权利。本文档中的信息是罗拉的财产联盟(“联盟”)及其使用和披露受罗拉联盟企业规章制度、知识产权(IPR)政策和会员协议。罗拉联盟规范的元素可能会受制于第三方知识产权,包括但不限于专利、版权或商标权利(第三方可能是也可能不是罗拉联盟的一员)。联盟不负责,不应以任何方式负责识别或未能识别任何或所有这些第三方知识产权。这个文件和本文所包含的信息提供了一个“是”的基础上,联盟
复制链接

扫一扫