Lorawan协议说明书Word下载.docx
《Lorawan协议说明书Word下载.docx》由会员分享，可在线阅读，更多相关《Lorawan协议说明书Word下载.docx（41页珍藏版）》请在冰点文库上搜索。
LoRa是由Semtech面向长距离、低功耗、低速率应用而开发的无线调制技术。
本文档中，将ClassA基础上实现了更多功能的设备称为“更高class终端”。
LoRa网络包含基础LoRaWAN（称之为ClassA）和可选功能（ClassB，ClassC）:
图Classes
双向传输终端（ClassA）：
ClassA的终端在每次上行后都会紧跟两个短暂的下行接收窗口，以此实现双向传输。
传输时隙是由终端在有传输需要时安排，附加一定的随机延时（即ALOHA协议）。
这种ClassA操作是最省电的，要求应用在终端上行传输后的很短时间内进行服务器的下行传输。
服务器在其他任何时间进行的下行传输都得等终端的下一次上行。
划定接收时隙的双向传输终端（ClassB）：
ClassB的终端会有更多的接收时隙。
除了ClassA的随机接收窗口，ClassB设备还会在指定时间打开别的接收窗口。
为了让终端可以在指定时间打开接收窗口，终端需要从网关接收时间同步的信标Beacon。
这使得服务器可以知道终端正在监听。
最大化接收时隙的双向传输终端（ClassC）：
ClassC的终端基本是一直打开着接收窗口，只在发送时短暂关闭。
ClassC的终端会比ClassA和ClassB
更加耗电，但同时从服务器下发给终端的时延也是最短的。
文档范围
这份LoRaWAN协议还描述了与ClassA不同的其他Class的额外功能。
更高Class的终端必须满足ClassA定义的所有功能。
注意：
物理层帧格式，MAC帧格式，以及协议中更高class和ClassA相同的内容都写在了ClassA部分，避免内容重复。
第3章PHY帧格式
LoRa有上行消息和下行消息。
上行消息
上行消息是由终端发出，经过一个或多个网关转发给网络服务器。
上行消息使用LoRa射频帧的严格模式，消息中含有PHDR和PHDR_CRC。
载荷有CRC校验来保证完整性。
PHDR，PHDR_CRC及载荷CRC域都通过射频收发器加入。
上行PHY:
Preamble
PHDR
PHDR_CRC
PHYPayload
CRC
图2.上行PHY帧格式
下行消息
下行消息是由网络服务器发出，经过单个网关转发给单个终端。
下行消息使用射频帧的严格模式，消息中包含PHDR和PHDR_CRC。
下行PHY:
图3.下行PHY帧格式
接收窗口
每个上行传输后终端都要开两个短的接收窗口。
接收窗口开始时间的规定，是以传输结束时间为参考。
图4.终端接收时隙的时序图
第一接收窗口的信道，数据速率和启动。
第一接收窗口RX1使用的频率和上行频率有关，使用的速率和上行速率有关。
RX1是在上行调制结束后的RECEIVE_DELAY1秒打开。
上行和RX1时隙下行速率的关系是按区域规定，详细描述在[LoRaWAN地区参数]文件中。
默认第一窗口的速率是和最后一次上行的速率相同。
第二接收窗口的信道，数据速率和启动。
第二接收窗口RX2使用一个固定可配置的频率和数据速率，在上行调制结束后的RECEIVE_DELAY2秒打开。
频率和数据速率可以通过MAC命令（见第5章）。
默认的频率和速率是按区域规定，详细描述在[LoRaWAN地区参数]文件中。
接收窗口的持续时间
接收窗口的长度至少要让终端射频收发器有足够的时间来检测到下行的前导码。
接收方在接收窗口期间的处理
如果在任何一个接收窗口中检测到前导码，射频收发器需要继续激活，直到整个下行帧都解调完毕。
如果在第一接收窗口检测到数据帧，且这个数据帧的地址和MIC校验通过确认是给这个终端，那终端就不必开启第二个接收窗口。
网络发送消息给终端
如果网络想要发一个下行消息给终端，它会精确地在两个接收窗口的起始点发起传输。
接收窗口的重要事项
终端在第一或第二接收窗口收到下行消息后，或者在第二接收窗口阶段，不能再发起另一个上行消息。
其他协议的收发处理
节点在LoRaWAN收发窗口阶段可以收发其他协议，只要终端能满足当地要求以及兼容LoRaWAN协议。
2梳理解析
LoRaWAN第3章，主要是讲了接收窗口这回事，只要记住张图就行。
目前RX1一般是在上行后1秒开始，RX2是在上行后2秒开始。
3源码分析
源码流程
在梳理这章节的对应代码时，自己手动做了张思维导图。
有时是这样，代码再有层次感，也不及一个图。
好，请收下。
发送完成就开始RX1和RX2延时
staticvoidOnRadioTxDone（void）
{
...
.
}
接收窗口的射频处理
从上面一步，我们已经清晰的知道，对应的处理肯定是在OnRxWindow1TimerEvent和OnRxWindow2TimerEvent中。
这两个接收窗口的处理，会对速率和信道进行设置，按照LoRaWAN协议中文版_配套文件地区参数（物理层）
中对各地区的要求分别进行处理。
比如这个470的处理，对上行信道对48取余得到下行信道。
RxWindowSetup（LORAMAC_FIRST_RX1_CHANNEL+（Channel%48）*LORAMAC_STEPWIDTH_
第4章MAC帧格式
LoRa所有上下行链路消息都会携带PHY载荷，PHY载荷以1字节MAC头（MHDR）开始，紧接着MAC载荷（MACPayload），最后是4字节的MAC校验码（MIC）。
射频PHY层：
图5.射频PHY结构（注意CRC只有上行链路消息中存在）
PHY载荷：
MHDR
MACPayload
MIC
或者
Join-Request
Join-Response
图载荷结构
MAC载荷：
FHDR
FPort
FRMPayload
FHDR：
DevAddr
FCtrl
FCnt
FOpts
图8.帧头结构
图帧格式元素（即图5~8）
MAC层（PHYPayload）
Size（bytes）
1
1..M
4
MACPayload字段的最大长度M，在第6章有详细说明。
MAC头（MHDR字段）
Bit#
7..5
4..2
1..0
MHDRbits
MType
RFU
Major
MAC头中指定了消息类型（MType）和帧编码所遵循的LoRaWAN规范的主版本号（Major）。
消息类型（MType位字段）
LoRaWAN定义了六个不同的MAC消息类型：
joinrequest,joinaccept,unconfirmeddataup/down,以及confirmeddataup/down。
描述
000
JoinRequest
001
JoinAccept
010
UnconfirmedDataUp
011
UnconfirmedDataDown
100
ConfirmedDataUp
101
ConfirmedDataDown
110
111
Proprietary
表消息类型
Join-requestandjoin-accept消息
join-request和join-accept都是用在空中激活流程中，具体见章节
Datamessages
Datamessages用来传输MAC命令和应用数据，这两种命令也可以放在单个消息中发送。
Confirmed-datamessage接收者需要应答。
Unconfirmed-datamessage接收者则不需要应答。
Proprietarymessages用来处理非标准的消息格式，不能和标准消息互通，只能用来和具有相同拓展格式的消息进行通信。
不同消息类型用不同的方法保证消息一致性，下面会介绍每种消息类型的具体情况。
数据消息的主版本（Major位字段）
Major位字段
00
LoRaWANR1
01..11
表列表
Major定义了激活过程中（joinprocedure）使用的消息格式（见章节）和MACPayload的前4字节（见第4章）。
终端要根据不同的主版本号实现不同最小版本的消息格式。
终端使用的最小版本应当提前通知网络服务器。
MAC载荷（MACPayload）
MAC载荷，也就是所谓的“数据帧”，包含：
帧头（FHDR）、端口（FPort）以及帧载荷（FRMPayload），其中端口和帧载荷是可选的。
帧头（FHDR）
FHDR是由终端短地址（DevAddr）、1字节帧控制字节（FCtrl）、2字节帧计数器（FCnt）和用来传输MAC命令的帧选项（FOpts，最多15个字节）组成。
Size（bytes）
2
0..15
FCtrl在上下行消息中有所不同，下行消息如下：
7
6
5
[3..0]
FCtrlbits
ADR
ADRACKReq
ACK
FPending
FOptsLen
上行消息如下：
帧头中自适应数据速率的控制（ADR,ADRACKReqinFCtrl）
LoRa网络允许终端采用任何可能的数据速率。
LoRaWAN协议利用该特性来优化固定终端的数据速率。
这就是自适应数据速率（AdaptiveDataRate（ADR））。
当这个使能时，网络会优化使得尽可能使用最快的数据速率。
移动的终端由于射频环境的快速变化，数据速率管理就不再适用了，应当使用固定的数据速率。
如果ADR的位字段有置位，网络就会通过相应的MAC命令来控制终端设备的数据速率。
如果ADR位没设置，网络则无视终端的接收信号强度，不再控制终端设备的数据速率。
ADR位可以根据需要通过终端及网络来设置或取消。
不管怎样，ADR机制都应该尽可能使能，帮助终端延长电池寿命和扩大网络容量。
即使是移动的终端，可能在大部分时间也是处于非移动状态。
因此根据它的移动状态，终端也可以请求网络使用ADR来帮助优化数据速率。
如果终端被网络优化过的数据速率高于自己默认的数据速率，它需要定期检查下网络仍能收到上行的数据。
每次上行帧计数都会累加（是针对于每个新的上行包，重传包就不再增加计数），终端增加ADR_ACK_CNT计数。
如果直到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，因为无法帮助提高链路距离。
不要ADRACKReq立刻回复，这样给网络预留一些余量，让它做出最好的下行调度处理。
上行传输时，如果ADR_ACK_CNT>
=ADR_ACK_LIMIT并且当前数据速率比设备的最小数据速率高，就要设置ADRACKReq，其它情况下不需要。
消息应答位及应答流程（ACKinFCtrl）
收到confirmed类型的消息时，接收端要回复一条应答消息（应答位ACK要进行置位）。
如果发送者是终端，网络就利用终端发送操作后打开的两个接收窗口之一进行回复。
如果发送者是网关，终端就自行决定是否发送应答。
应答消息只会在收到消息后回复发送，并且不重发。
为了让终端尽可能简单，尽可能减少状态，在收到confirmation类型需要确认的数据帧，需要立即发送一个严格的应答数据帧。
或者，终端会延迟发送应答，在它下一个数据帧中再携带。
重传流程
当需要应答却没收到应答时就会进行重发，重发的个数由终端自己定，可能每个终端都不一样，这个参数也可以由网络服务器来设置调整。
一些应答机制的示例时序图在第18章中有提供。
如果终端设备重发次数到达了最大值，它可以降低数据速率来重连。
至于后面是否再重发还是说丢弃不管，都取决于终端自己。
如果网络服务器重发次数到达了最大值，它就认为该终端掉线了，直到它再收到终端的消息。
一旦和终端设备的连接出现问题时，要不要重发都取决于网络服务器自己。
在重传期间的数据速率回退的建议策略在章节中有描述。
帧挂起位（FPendinginFCtrl只在下行有效）
帧挂起位（FPending）只在下行交互中使用，表示网关还有挂起数据等待下发，需要终端尽快发送上行消息来再打开一个接收窗口。
FPending的详细用法在章节。
帧计数器（FCnt）
每个终端有两个计数器跟踪数据帧的个数，一个是上行链路计数器（FCntUp），由终端在每次上行数据给网络服务器时累加；
另一个是下行链路计数器（FCntDown），由服务器在每次下行数据给终端时累计。
网络服务器为每个终端跟踪上行帧计数及产生下行帧计数。
终端入网成功后，终端和服务端的上下行帧计数同时置0。
每次发送消息后，发送端与之对应的FCntUp或FCntDown就会加1。
接收方会同步保存接收数据的帧计数，对比收到的计数值和当前保存的值，如果两者相差小于MAX_FCNT_GAP（要考虑计数器滚动），接收方就按接收的帧计数更新对应值。
如果两者相差大于MAX_FCNY_GAP就说明中间丢失了很多数据，这条以及后面的数据就被丢掉。
LoRaWAN的帧计数器可以用16位和32位两种，节点上具体执行哪种计数，需要在带外通知网络侧，告知计数器的位数。
如果采用16位帧计数，FCnt字段的值可以使用帧计数器的值，此时有需要的话通过在前面填充0（值为0）字节来补足；
如果采用32位帧计数，
FCnt就对应计数器32位的16个低有效位（上行数据使用上行FCnt，下行数据使用下行FCnt）。
终端在相同应用和网络密钥下，不能重复用相同的FCntUp数值，除非是重传。
帧可选项（FOptsLeninFCtrl,FOpts）
FCtrl字节中的FOptsLen位字段描述了整个帧可选项（FOpts）的字段长度。
FOpts字段存放MAC命令，最长15字节，详细的MAC命令见章节。
如果FOptsLen为0，则FOpts为空。
在FOptsLen非0时，则反之。
如果MAC命令在FOpts字段中体现，port0不能用（FPort要么不体现，要么非0）。
MAC命令不能同时出现在FRMPayload和FOpts中，如果出现了，设备丢掉该组数据。
端口字段（FPort）
如果帧载荷字段不为空，端口字段必须体现出来。
端口字段有体现时，若FPort的值为0表示FRMPayload只包含了MAC命令；
具体见章节中的MAC命令。
FPort的数值从1到223（0x01..0xDF）都是由应用层使用。
FPort的值从224到255（0xE0..0xFF）是保留用做未来的标准应用拓展。
7..23
0..1
0..N
N是应用程序载荷的字节个数。
N的有效范围具体在第7章有定义。
N应该小于等于：
N<
=M-1-（FHDR长度）
M是MAC载荷的最大长度。
MAC帧载荷加密（FRMPayload）
如果数据帧携带了载荷，FRMPayload必须要在MIC计算前进行加密。
加密机制是采用的AES128算法。
默认的，加密和加密由LoRaWAN层来给所有的FPort来执行。
如果加密/解密由应用层来做更方便的话，也可以在LoRaWAN层之上给特定FPorts来执行，除了端口0。
具体哪个节点的哪个FPort在LoRaWAN层之外要做加解密，必须要和服务器通过out-of-band信道来交互（见第19章）。
LoRaWAN的加密
密钥K根据不同的FPort来使用：
K
NwkSKey
1..255
AppSKey
表3:
FPort列表
具体加密是这样：
pld=FRMPayload
对于每个数据帧，算法定义了一个块序列Ai，i从1到k，k=ceil（len（pld）/16）：
Ai
0x01
4x0x00
Dir
FCntUporFCntDown
0x00
i
方向字段（Dir）在上行帧时为0，在下行帧时为1.
块Ai通过加密，得到一个由块Si组成的序列S。
Si=aes128_encrypt（K,Ai）fori=1..k
S=S1|S2|..|Sk
通过异或计算对payload进行加解密：
LoRaWAN层之上的加密
如果LoRaWAN之上的层级在已选的端口上（但不能是端口0，这是给MAC命令保留的）提供了预加密的FRMPayload给LoRaWAN，LoRaWAN则不再对FRMPayload进行修改，直接将FRMPayload从MACPayload传到应用层，以及从应用层传到MACPayload。
消息校验码（MIC）
消息检验码要计算消息中所有字段。
msg=MHDR|FHDR|FPort|FRMPayload
MIC是按照[RFC4493]来计算：
cmac=aes128_cmac（NwkSKey,B0|msg）
MIC=cmac[0..3]
块B0的定义如下：
B0
0x49
len（msg）
方向字段（Dir）在上行帧时为0，在下行帧时为1.
LoRaWAN第4章，主要讲述了MAC帧格式，对所有涉及的字段都做了解释。
千言万语汇成一句话，哦不，汇成一个表。
数据帧头
数据帧
MAC层
PHY层
好了，帧格式是大家随手都能看到的东西，本尊作为IoT小能手，如果不能提出一些稍有深度的信息增量，就对不起这个称号了。
所以，有些协议设计层面的心得要分享下：
1.特别酷的ADR（速率自适应）机制
这个章节中最亮眼的莫过于速率自适应机制，简直是为LoRa网络量身定做的：
一旦使能了FCtrl中的ADR位，距离近信号好的节点用高速率，距离远信号弱的节点用低速率，不小心被调高了速率，则自动降下来。
这样，尽可能地提高了传输速率，也有效提高了网络容量。
我已经见过不少厂家，拿这个协议的公知特点当产品卖点了。
2.可同时携带数据和命令的MAC帧
一般来说，应用除了数据，出于管理需要，肯定还会涉及命令。
比如基站要查询节点状态，或者节点要请求变更信道等。
所以LoRaWAN协议设计上利用FOpts把数据和命令揉在一个MAC帧里，这样可以提高交互效率，有效地降低功耗。
这在寸土寸金，哦不，寸
升级会员 