LoRaWAN协议

LoRaWAN协议定义了使用LoRa的MAC层规范，处在协议应用层与物理层中间的实现规范。LoRa没有开放的规范化物理层协议，而LoRa物理模块的接口上很多参数都可以进行配置，LoRaWAN同时对一些数据发送格式做了相应的限制。

物理层消息结构

上行带有CRC，而下行没有。

层间组包格式

简要参数说明：DevAddr 为设备地址(包含网络地址信息),Fport复用port域，如果为0表示有效负载为MAC命令，此时FOptsLen为0；FOptsLen:options长度为，FCnt为帧计数；MIC加密完整性检查包含MHDR和FHDR FPort和 FRMPayload;MType为消息类型，指示上下行消息及是否是需要Confirm的消息，如果是confirmed消息则需要回复ACK。Major是LoRaWAN的版本号；ADR 和 ADRAckReq提供服务端用于自适应数据速率控制；ACK确认最新的帧信息；FOpts用于在发送数据时同时携带MAC Command；CID为MAC 命令ID，Args为命令参数；FRMPayload为使用key长128比特AES加密的有效数据。MAC header的最小长度为13字节，最大为28字节；上行没有目标地址，而下行没有源地址。上图不是协议上原始的消息结构图，协议结构图如下，对于每个元素的细节展开参考规范LoRaWAN-v1.1.pdf RFU 填充为0，需要省略的单元MType亦即message type依赖在相应版本Major下的消息类型。FPort如果payload不为空，则FPort必须存在如果FRMPayload只有MAC commands则此域为0。1-223用于上层应有端口，224用于MAC协议测试，225-255留给后续协议扩展。

三种终端类型

三种终端类型，classA、classB、classC，其耗能和数据延时比较如下,而classB和classC的终端可支持组播方式。

ClassA类型终端收发方式如下: 在上行发送后，Receive_Dealy误差+/-20微秒时刻进行下行接收，如果网络在RX1和RX2都发送给同一终端数据，则需要发送同帧数据。终端如果在RX1成功接收到检查成功的数据，则不可再在RX2继续接收数据。RX1的频率和速率和上行发送的频率和速率满足一定的函数关系式(在相关流程中说明)，在缺省情况下第一个窗口的数据传输速率和上行发送相同，第二个窗口则采用固定可配置的频率和速率，可以通过MAC Command进行配置。窗口长度至少足够检测下行的preamble，如果检测到下行的preamble，则需要接收到相应frame解调结束。网络需要在RX1或RX2窗口边界才能开始发起数据。终端在前一次上行发送成功后如果没有正确解码到下行数据并且RX2窗口仍未超时的情况下，不可再次出发上行发送。

ClassB类型的终端，在支持CLassA类型的接收方式之外，还需周期性监测网络下行的ping slot，而为了实现周期性的同步，引入beacon来携带时间信息，终端可以利用beacon(beacon周期性128秒进行发送，ping slot周期可配置)进行时、频估计，并作出相应调整。ping slot和Beacon的时序关系如下，Beacon由网关周期性发送。Beacon携带4个字节时间信息，单位为秒(Sunday 6th of January 1980 的0点开始计时),同时携带还有GwSpecific及CRC等。ClassA、ClassB转换通过ClassB比特位来进行。ClassB: 设置为1时，告诉网络服务器端，设备切换到ClassB模式。而在ClassA模式下，为保证能够尽快接收到下行数据，引入Frame Pending bit Fpending inFCtrl只用在下行，表示下行仍有数据发送，需要终端尽快发送上行以打开下行接收窗口。Beacon丢失后可以维持2小时，此时终端根据自身条件维护时间，在此种情况，需要扩展ping和beacon的接收窗口来补偿频率及时间补漂移。对于移动中的终端，GwSpecific 可以携带GPS坐标信息,由于classB需要网关发送ping消息，网络需要知道距离终端最近的网关位置。两种方式来保证设备部丢失：周期性上行发送以或是小区变化时的上行发送，前者不需要检测gateway specific，而后者需要通过此ID来判断小区变化。beacon和ping slot亦可使用跳频发送。

Beacon的周期性发送方式及时序关系如下,DeviceTimeReq可以用于请求网络时间，加快Beacon的发现过程。

ClassC模式的工作流程如下，支持ClassC的终端需要支持ClassA，不需支持classB，ClassC终端在发送时刻以外尽可能长时间处在下行接收状态。ClassA和ClassC的模式转换通过MAC命令来进行（DeviceModeInd 和 DeviceModeCnf）。

消息类型

消息类型，message type的类型如下，消息中主要指示负载数据类型或者Join流程消息类型。

Conifrmed Data需要接收端进行相应数据包的ACK应答，而Uncofirmed则是无应答要求数据。Joint / Rejoint程序用于OTA激活程序处理。数据消息可以传输MAC指令或应用层数据(可合并一起发送)。Confirmed消息是需要进行ACK确认的消息。Proprietary专用消息可用于非标准消息，但必须和标准消息不冲突，当终端或服务端不能识别相应消息时刻，可以选择丢弃该消息。

Joint request包含JoinEUI DevEUI和DevNonce(2个字节，上电时值为0,每次发送Joint-request值加一，掉电时需要保留在NVM中non-volatile memory)，网络跟踪DevNonce值的变化，如果没有改变的Joint-Request将作为无效消息丢弃。Joint-Request消息无需加密。

Join-accept如果网络允许设备接入则会回复这条消息。使用跳频技术的随机接入，Join-Accept接收和ClassA下行接收类似，不过RX1和RX2的delay为JOIN_ACCEPT_DELAY1和JOIN_ACCEPT_DELA2由物理层特性定义。在join-accept成功后，需要发送RekeyInd、RekeyConf进行交互开启新的加密模式。如果不允许终端接入，则网络不会给终端任何回复。joint-accept中包含信息：JoinNonce、NetID、DevAddr、DLSettings、RxDelay、CFList。home_NetID为设备归属网络的ID，属于NetID一类。DLsettings包含OptNeg，指示网络为1.0或是1.1，unset为1.0版本，set为1.1及其后续版本，包含RX1DRoffset(第一个接收窗和上行速率关系)，和RX2Data rate(速率大小索引)。JoinNonce用来获取FNwkSIntKey,SNwkSIntKey, NwkSEncKey、AppSKey。JoinNonce每次处理Join-accept则加一。Join-Nonce需要一直累加，并且终端判断该值不大于存储值时认为消息无效。NetID24比特，当为私人或实验网络时，分配地址如下：

Rejoin的流程和Join-request类似，同样回复join-accept。JoniReqType分为0xFF Join-request，0x00Rejoin-request type0，0x01 Rejoi、n-request type1，0x02：Rejon-request type2。Rejon-accept用于网络间的切换，维持或改变设备在已有网络上的地址。Rejoin-request，0包含NetID+DevEUI，重置所有无线相关参数。type1包含JoinEUI+DevEUI，作用和Joint-request类似，type3包含NetID+DevEUI，维护或改变设备地址，seesion秘钥，帧号等，无线资源参数不变化。

设备激活

Join流程的作用是用于终端激活，终端激活的作用，是当设备刚开始工作时完成在相应网络初始化的过程，没有显式定义的去激活过程，只能通过应用层处理。在终端接入LoRaWAN网络进行有效服务之前，需要进行激活。激活的方式有两种OTAA(Over-The-Air-Activation)和ABP(Activation By Personalization)。激活过程需要完整一些信息确认，DevAddr占用32比特，7bit用于指示网络，25比特指示终端在网络中的地址ID。得到的NwkKey、AppKey是用于产生终端完整保护及数据加密key的基础，LoRaWAN采用AES128比特算法作为数据加密基础。激活的流程参考

Join处理流程

加密及数据完整性保护

LoRaWAN为了提高数据的安全性、可靠性，提供了加密和完整性保护MIC。Device root keys (AppKey & NwkKey) 为IEEE 802.15.4 中AES-128比特的密钥，在OTAA模式下，NwkKey 用来产生FNwkSIntKey,SNwkSIntKey和NwkSEncKey，而AppKey用来产生AppSKey。在v1.0版本中AppSKey亦是由NwkKey产生的。只支持ABP模式的设备不需要NwkKey和Appkey。JSIntKey和JSEncKey也是从NwkKey来得到，前者用于Rejoin-Request type1和对应Join-Accept回复的MIC，后者用于加密Rejoin-Request触发的Join-Accept。在激活之后，终端可以得到的信息: DevAddr NwkSEncKey SNwkSIntKey FNwkSIntKey及AppSKey。DevAddr用于指示终端在当前网络中的身份，由于AddrPrefix和NwkAddr组成，AddrPrefix由网络服务器身份NetID获取。DevAddr共占用32比特，其中有7：24比特用来表示AddrPrefix，其他表示NwkAddr。AddrPrefix有Lora联盟分配，私有网络和实验网络可以用7比特b0000000和b0000001表示。如果使用OTAA方式，需要采用join程序进行交互，joint-request用于发起请求，而join-accept用于网络应答，同时终端可以得到NwKkey和AppKey，在ABP模式下不需要通过Join流程来完成信息交互，设备端本身存有所需的DevAddr、FNwkSIntKey, SNwkSIntKey, NwkSEncKey 和AppSKey。OTAA模式下需要终端携带JointEUI、DevEUI，前者是网络中设备标识，而后者是设备全球唯一标识。当ABP模式设备接入网络时，首先应当触发ResetInd/ResetCnf流程。而在OTAA模式设备上需要完成Joint程序后出发RekeyInd、RekeyConf流程(只在OTA模式及1.1的网络中支持，用于确认密钥更新)。Key的产生过程在V1.0和V1.1中略有差别，具体参考如下

V1.0版本中的产生方式

V1.1版本中的产生方式

MAC Command处理

LoRaWAN的MAC命令提供了有效定制终端参数的方式，如LinkCheckReq可以用于终端测试其连接情况，其他的命令都是提供服务端使用，这些命令可以用于控制的终端的数据速率、功率输出、数据重传次数，接收周期、接收窗口等配置参数；同时还有一些命令可以用于请求终端报告电池、接收质量等相关信息。MAC指令可以作为有效的数据内容携带在FRMPayLoad里面同时FPort设置为0，也可以与数据共存，放置在FOpts中，此种情况下最长15字节。每个ID(command identifer)占用1个字节。MAC指令按照接收顺序处理回复，同一帧收到的MAC指令必须在同一帧内进行回复。优先发送MAC指令回复在FOpts和FRMPayload，如果超过FRMPayload长度，则只发送可发长度，网络服务端将对为回复的MAC指令进行重新发送。网络计算MAC指令回复内容FRMPayload Size的方式：在ADR为0是认为最大FRMPayload为最低速率，ADR比特为1时网络认为最大Payload size为上次上行发送速率对应的大小。设备只对接收到的MAC命令做一次回复，如果消息丢失，网络需要重发命令。网络在接收到新的上行而没有对MAC命令回复时决定是否需要重发命令，由于RxParamSetupReq、RxTimingSetup和DlChannelReq影响下行信道参数，他们的ACK方式有所不同。网络需要在RX1、RX2窗口回复终端的MAC命令，如果终端没有收到回复，则自主调度重传机制。

MAC命令交互及功能

ClassB增加

ClassC增加

自适应速率控制 ADR(Adaptive data rate control)

如果上行ADR设置为1，则网络可以通过MAC命令进行速率和发送功率的控制，否则网络不会尝试改变速率或发送功率，但可能改变信道和数据重复次数。如果下行ADR设置为1只表明网络处于可以进行ADR控制的状态。如果下行ADR比特位0，在移动的终端则需要reset上行ADR比特，按照自身策略进行速率控制，而静止的终端则忽略此状态，进行正常ADR控制。LinkADRReqMAC指令可以用于调整速率和功率。终端发送功率默认为最大值或当地允许的最大值，如果网络终端的速率大于缺省的速率或者发送功率小于缺省的功率，终端需要周期确认网络能够收到上行帧。为了实现这个功能，引入ADR_ACK_CNT计数器，如果发送次数(重复传输不计算在内，只考虑新的数据传输)超过门限设置ADR_ACK_LIMIT时仍未收到下行的任何数据，则需要设置ADRACKReq比特位，网络需要在ADR_ACK_DELAY帧长时间内做出回复，下行接收到数据，则复位ADR_ACK_CNT计数器。如果在ADR_ACK_LIMIT + ADR_ACK_DELAY时间内网络没有回复，终端需要通过回复缺省配置功率和降低速率的方式重新连接，当ADR_ACK_DELAY超时时速率一步步进行降低，如果一直到达最低速率都未能重新获得连接，终端需要重新恢复功率、速率、频点信道初始配置。当速率和功率和缺省值相等时，表示无法提升连接性能，此时ADRACKReq不应使用，三个条件可触发此流程: 速率高于缺省速率、配置功率小于缺省功率或是目前配置的可用信道为缺省可用信道的子集。

数据的ACK与重传

当数据为Confirmed模式需要ACK的时候，网关需要在终端上行打开的下行周期进行发送，而终端则可自行调度，ACK只针对最新收到的数据进行。在没有收到ACK的情况，服务端采用新的帧号进行发送。而上行confirmed 和unconfirmed帧都是重传NbTrans次，除非收到下行有效传输。重传次数可以由网络根据不同的Qos配置，重传间可以使用跳频，而重传间隔各个终端可以自行决定。而设备收到ACK时需要停止相应帧的重复传输。对于uncofirmed数据，ClassA在RX1或RX2收到有效数据则停止重复发送，calssB&C在RX1收到数据时停止重复发送。NbTrans上行传输次数，对confirmed和unconfirmed消息都采用，缺省值为1，有效范围1-15，如果接收到的配置值为0，则保持现有值不变。

FCnt: Frame counter，在LoRaWAN1.1版本设备需要维护三个计数器，而在1.0之前版本只需要两个，差别在于原来计数分上行下行两个FCntUp和FCntDown，而在1.1后的版本采用单独的NFCntDown用于MAC交互的port0和Fport未存在的时刻，而AFCntDown用于其他port，逻辑上NFCntDown由网络服务端维护，AFCntDown由应用服务器端维护。在OTAA模式下，当成共处理Joint-accept时刻，将Frame Counter全部reset到0，而在ABP设备上初始为0，在设备存货周期内都不会重置，甚至掉电也需维持。计数器总共32比特，而发送在消息中的FCnt只有最后16比特，设备对于重复的数据只需ACK一次。

关于信道配置

参考LoRaWAN-Regional-Parameters-v1.1rA.PDF，由于ISM属于非授权公共免费频谱，但需要满足一定的限制条件，各个频率及地区限制以及相适应的物理参数在文档中做了详细的说明。

名词解释

FNwkSIntKey: Forwarding Network session integrity key

SNwkSIntKey: Serving Network session integrity key

NwkSEncKey: Network session encryption key v1.0中mac payload的MIC和加密key相同。

AppSKey: Application session key ()用于应用层服务端和设备端的数据加密。

Session Context 分为Network Session和Application Session，network session上下文包括信息F/SNwkSIntKey、NwkSEncKey 、FCntUp 、FCntDwn (LW 1.0) or NFCntDwn (LW 1.1)、DevAddr。Application session上下文包括：AppSKey 、FCntUp 、FCntDown (LW 1.0) or AFCntDwn (LW 1.1)。

OTAA: Over-The-Air Activationvia

ABP: Activation By Personalization

MIC: message integrity code